
* Menu

* 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).


	***********************************************
	* 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 verision (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 disapears.  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 when moving the cursor.


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

1.   We can't *really* move a file on such filesystems.  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 "filesystem" dependent code.  Sorry.  In fact, my real problem
wasn't that stupid MS-DOG filesystem, but the impossibility of detecting
such filesystems.  The 'move' command will normally fail on filesystems with
no support for hard links, but under Linux it *will* work with MS-DOG
filesystems because I know MS-DOG lacks working hard links and I've put a
small test in the right place :-).
