[Debian GNUstep maintainers] Bug#592751: Broken on hppa; programs abort with malloc assertion failure

[Yavor Doganov]

On Wed, Aug 18, 2010 at 12:50:39PM -0600, dann frazier wrote:
> _gnu_process_args (argc=1, argv=0x3cb98, env=0x3bd08) at NSProcessInfo.m:233
> 233	NSProcessInfo.m: No such file or directory.
> 	in NSProcessInfo.m
> 238	in NSProcessInfo.m
> 240	in NSProcessInfo.m
> *__GI_strlen (str=0xfaf00992 "test") at strlen.c:42

So, this time the abort is at a different place, way more earlier,
when trying to allocate memory for the process name.

  if (argv != 0 && argv[0] != 0)
    {
      _gnu_arg_zero = (char*)objc_malloc(strlen(argv[0]) + 1);
      strcpy(_gnu_arg_zero, argv[0]);
      arg0 = [[NSString alloc] initWithCString: _gnu_arg_zero];
    }

How a simple `strlen ("test")' would lead to this is mystifying.

The backtrace from yesterday's program (the NSNotificationCenter test)
is also a riddle:

#13 mapNew (self=0x3cb88, _cmd=<value optimized out>, observer=<value
optimized out>, selector=<value optimized out>, name=0x50118,
object=0x0) at NSNotificationCenter.m:326

Here, there's no map for this name (valid scenario), so one is
created, but it again fails while allocating memory for the map
table...

No clue, and unfortunately upstream does not have either:

,----
| The fact that very different stacktraces are showing crashes in malloc
| suggests that the problem is memory corruption which occurred
| elsewhere (and there are probably no real clue to the original cause
| in the stacktraces). This suggests that using gdb is unlikely to be
| helpful initially.
| 
| In which case, the only approach which really offers any reasonable
| prospect of success would be to check out base from svn trunk on
| various dates, and see at what point the test program starts
| crashing. That will narrow things down to the code change at which
| crashing started ... at which point we can examine the source to see
| if we can spot anything, and also run under gdb setting breakpoints at
| any changed section of code, and stepping through to see what's going
| on.
`----

So, seeing no other way out, I suggest to try bisecting.

Please start from the tip, just in case the issue is gone accidentally
(that would be a miracle, but well, who knows).  Then skip directly to
the last known "bad" revision 30325 (that's 1.20.0, which you already
confirmed has the problem).  The last "good" is r28586 (1.19.3).

I think this would be the easiest way:

1) . /usr/share/GNUstep/Makefiles/GNUstep.sh
   (This sets up PATH, LD_LIBRARY_PATH, GNUSTEP_MAKEFILES, etc.)

2) Make sure the variables at /usr/share/GNUstep/Makefiles/config.make
   are not set to gcc-4.3; we definitely want to test with the default
   compiler/ObjC runtime.

3) Run ./configure --enable-libffi --disable-openssl --disable-bfd
   (For consistency with how the Debian package is configured.)

4) make install GNUSTEP_INSTALLATION_DOMAIN=USER
   This will put stuff in ~/GNUstep, which you can safely delete after
   that.

5) The tools will end up in ~/GNUstep/Tools, which should be in $PATH
   if you sourced GNUstep.sh as per 1).

6) The good/bad test would be the exit status of `gdnc --help'.


Apologies in advance for the extra tedious work...