
* Menu

* SCO 3.2 V 4.2 problems.
* SIGSEGV under Linux when debugging with gdb.
* configure stopping before generating the Makefiles.
* SLACKWARE Linux 1.2.0 / 2.0.0 termcap/terminfo problems.
* Linux color_xterm problems.
* File systems with no support for hard links (MS-DOG).
* Newer Linux kernels with /dev/vcs.


	**************************
	* SCO 3.2 V 4.2 problems *
	**************************

     Han Holl <100327.1632@compuserve.com> has reported some problems running
git-4.3.5 on SCO Unix 3.2 V 4.2: 

1.    GIT didn't work with the ordinary malloc library:
>   I used './configure --enable-terminfo', and added -lmalloc to the LIBS
> variable (it crashed with the ordinary malloc library). I used gcc.

2.    Also, in the src/Makefile fnmatch.o should be added to GITMATCH_OBJS and
GIT_OBJS "by hand":
> Strangely enough, gitmatch linked without explicitly linking in fnmatch,
> because there is in the SCO libc.a a fnmatch function, but it's completely
> undocumented, and doesn't seem to be compatible with the posix function.


	***********************************************
	* SIGSEGV under Linux when debugging with gdb *
	***********************************************

1.   When debugging git-4.3.5 under Linux with GDB I sometimes receive
a SIGSEGV signal.  This never happened when running git without using
the debugger.  Performing the same set of actions from outside the debugger
works fine.  It is quite strange and I have not been able to figure
out what the problem is.  Even while running under gdb, git receives the
SIGSEGV signal only sometimes, and only the first time I start it.  If I
have run git once and I want to reproduce the bug again, I cannot do it
without restarting the debugger.  The stack frames look like this:

(gdb) bt
#0  fatal_signal (signum=11) at ./signals.c:90
#1  0xbffff6ec in _end ()
#2  0xbb40 in __load_shared_libraries ()
#3  0x600c76b4 in _end ()
#4  0x18408 in _end ()
#5  0x18400 in _end ()
#6  0x183f8 in _end ()
#7  0x183f0 in _end ()
#8  0x183e8 in _end ()
#9  0x183e0 in _end ()
#10 0x183d8 in _end ()

0xbb34 <__load_shared_libraries+176>:	movl   $0x1,%eax
0xbb39 <__load_shared_libraries+181>:	pushl  %eax
0xbb3a <__load_shared_libraries+182>:	movl   0x5c(%esp,1),%eax
0xbb3e <__load_shared_libraries+186>:	call   *%eax
0xbb40 <__load_shared_libraries+188>:	movl   0x2c(%esp,1),%edx
0xbb44 <__load_shared_libraries+192>:	pushl  %edx
0xbb45 <__load_shared_libraries+193>:	movl   0x2c(%esp,1),%edx
0xbb49 <__load_shared_libraries+197>:	pushl  %edx
0xbb4a <__load_shared_libraries+198>:	call   0xba04 <__main+192>
0xbb4f <__load_shared_libraries+203>:	addl   $0x20,%esp

0xbffff6db <_end+3221164107>:	movl   $0x2b,%edi
0xbffff6e0 <_end+3221164112>:	addb   %al,(%eax)
0xbffff6e2 <_end+3221164114>:	addb   %al,(%eax)
0xbffff6e4 <_end+3221164116>:	addb   %al,(%eax)
0xbffff6e6 <_end+3221164118>:	addb   %al,(%eax)
0xbffff6e8 <_end+3221164120>:	addb   %al,(%eax)
0xbffff6ea <_end+3221164122>:	int    $0x80
0xbffff6ec <_end+3221164124>:	popl   %eax
0xbffff6ed <_end+3221164125>:	movl   $0x77,%eax
0xbffff6f2 <_end+3221164130>:	int    $0x80
0xbffff6f4 <_end+3221164132>:	addb   %al,(%eax)
0xbffff6f6 <_end+3221164134>:	addb   %al,(%eax)
0xbffff6f8 <_end+3221164136>:	xorb   %dh,0xf9086001
0xbffff6fe <_end+3221164142>:	(bad)  

So, it appears that the SIGSEGV signal occured while running some library
code.  It might be a problem related to a corrupted stack or a debugger/
C library problem.  I don't know, but since I have never had this problem
while running the program without the debugger, I have decided to release
this version (4.3.5).  I something bad will happen, I am sure I will hear
about it :-) .

	******************************************************
	* configure stopping before generating the Makefiles *
	******************************************************

1.   I have tested git on some computers at FSF.  There are some workstations
running the HP-UX 7.00 operating system and I have noticed that the configure
script stops *after* generating the config.status file but *before* generating
the Makefiles (Makefile, src/Makefile, info/Makefile and man/Makefile). Is
this an autoconf problem ?  I couldn't check this because the network was too
slow to allow me to edit the configure script and set some breakpoints :-(
It might also be a bash problem...


	***********************************************************
	* SLACKWARE Linux 1.2.0 / 2.0.0 termcap/terminfo problems *
	***********************************************************

1.   The 'ms' flag (safe to move in standout mode) is missing from the
console termcap database.  It is available  only in the console terminfo
database (its terminfo name is 'msgr').

2.   The 'sgr0' capability (according to the terminfo manual this is the
terminfo name of the termcap 'me' capability) is missing from the console
terminfo database but it is available in the termcap database.  This is a
problem for GIT when using terminfo because if we can't turn the reverse
video mode or the brightness off, we should not turn them on at all.  I've
solved the problem by using a hard-coded 'me' for the Linux console if I
can't find 'me' in the database, but I hate this method.  This is one of the
two reasons why I prefer using termcap under Linux (the second one is that
the executable linked with the termcap library is a lot smaller).

3.   The 'smacs' and 'rmacs' ('as' and 'ae' in termcap) are missing from
the console termcap database but are available in the console terminfo
database.

4.   'se' is \E[27m in termcap but 'rmso' (the terminfo equivalent) is
\E[0m in terminfo.  Are both ok ?


	******************************
	* Linux color_xterm problems *
	******************************

1.   Sometimes, when moving the cursor, color_xterm deletes useful
informations on the screen.  This is *NOT* an git bug because when
hiding/repainting the window, the garbage disappears.  I don't know
how to handle this.  The normal xterm (b/w) works fine.
   The Ultrix xterm understands standard ANSI color sequences but
has no problems moving the cursor.


	***********************************************
	* File systems with no support for hard links *
	***********************************************

1.   We can't *really* move a file on such file systems.  We have to copy
the source file to the destination and then remove the it.  MS-DOG programs
can perform a real move by copying the directory entry in the destination
directory but I don't think we can do this under UNIX and I don't feel like
writing MS-DOG "file system" dependent code.  Sorry.  In fact, my real problem
wasn't that stupid MS-DOG file system, but the impossibility of detecting
such file systems.  The 'move' command will normally fail on file systems with
no support for hard links, but under Linux it *will* work with MS-DOG
file systems because I know MS-DOG lacks working hard links and I've put a
small test in the right place :-).


	*************************************
	* Newer Linux kernels with /dev/vcs *
	*************************************

1.   Newer Linux kernels use /dev/vcs to dump the screen contents.  If you
are using GIT on such a system, you will probably find in your log file
messages saying that the old method (still used by GIT) of dumping the
screen contents is obsolete:

     linux: TIOCLINUX (0/8/9) ioctl is gone - use /dev/vcs

  In order to avoid filling up your log file with such message edit the
src/tty.c file and replace

#ifdef HAVE_LINUX
with
#if 0

at the beginning of the tty_get_screen() and tty_put_screen() functions.
This problem will be fixed in the next release.  Sorry, I don't have
access to such a Linux system right now.

