[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

[Richard Frith-Macdonald]

Update of bug #30766 (project gnustep):

 Open/Closed: In Test => Closed 

___

Follow-up Comment #28:

No update after several months.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

[Fred Kiefer]

Update of bug #30766 (project gnustep):

  Status:None => Ready For Test 
 Assigned to:  FredKiefer => CaS
 Open/Closed:Open => In Test


___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

[Riccardo mottola]

Follow-up Comment #27, bug #30766 (project gnustep):

I commited your patch, it works for me. Firther testing is advisable.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

[Riccardo mottola]

Follow-up Comment #26, bug #30766 (project gnustep):

on windows the patch appears to work.

___

Reply to this item at:

  

___
  Messaggio inviato con/da Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

[Yavor Doganov]

Follow-up Comment #25, bug #30766 (project gnustep):

Looks like pthread.h is not included in the test program.  See if the
attached patch helps.

(file #21281)
___

Additional Item Attachment:

File name: AC_CHECK_ALIGNOF.patch Size:0 KB


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

[Riccardo mottola]

Follow-up Comment #24, bug #30766 (project gnustep):

on windows the failure log is:

configure:15202: result: 4
configure:15221: checking alignment of pthread_mutex_t
configure:15550: gcc -o conftest.exe -g -O2 
-I/GNUstep/System/Library/Headers -
I/GNUstep/Local/Library/Headers -I/GNUstep/Local/Library/Headers
-I/GNUstep/Syst
em/Library/Headers  -L/GNUstep/System/Library/Libraries
-L/GNUstep/Local/Library
/Libraries -L/GNUstep/Local/Library/Libraries
-L/GNUstep/System/Library/Librarie
s conftest.c  >&5
conftest.c:148: error: syntax error before "pthread_mutex_t"^M
conftest.c:148: warning: no semicolon at end of struct or union^M
conftest.c:148: warning: data definition has no type or storage class^M
conftest.c: In function `longval':^M
conftest.c:149: error: syntax error before ')' token^M
conftest.c: In function `ulongval':^M
conftest.c:150: error: syntax error before ')' token^M
conftest.c: In function `main':^M
conftest.c:160: error: syntax error before ')' token^M
conftest.c:163: error: syntax error before ')' token^M
conftest.c:170: error: syntax error before ')' token^M
configure:15554: $? = 1
configure: program exited with status 1
configure: failed program was:
| /* confdefs.h.  */

___

Reply to this item at:

  

___
  Messaggio inviato con/da Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

[Yavor Doganov]

Follow-up Comment #23, bug #30766 (project gnustep):

How does it fail exactly?  Can you post the relevant portions from
config.log?

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

[Riccardo mottola]

Follow-up Comment #22, bug #30766 (project gnustep):

This fix breaks at least OpenBSD and Windows because configure fails.

___

Reply to this item at:

  

___
  Messaggio inviato con/da Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

[Yavor Doganov]

Follow-up Comment #21, bug #30766 (project gnustep):

Yes, I'm glad to confirm this fixes the problem.  It was not tested on the
official autobilders yet, but I doubt there will be any problems (and if there
are, they would be entirely my fault when incorporating the patch).

Thanks very much!

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

[Richard Frith-Macdonald]

Follow-up Comment #20, bug #30766 (project gnustep):

I added a tiny fix to svn trunk to set the alignment.  You could see if this
fixes things.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

[Yavor Doganov]

Follow-up Comment #19, bug #30766 (project gnustep):

I asked Carlos O'Donnel, the author of the glibc NPTL code for hppa if
there's something wrong in the approach of hiding pthread internals with
opaque types of the same size.  He said:

"Yes, you don't take into account the alignment requirement of the
structure.

The pthread_mutex_t and pthread_cond_t on hppa are __attribute__
((aligned(16))), which means if you embedded them into another
structure they need to be padded out to that alignment. The dummy
structure you use here doesn't match the alignment and may break ABI."

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

[Yavor Doganov]

Follow-up Comment #18, bug #30766 (project gnustep):

FWIW, link to the discussion that lead to this particular change:
http://thread.gmane.org/gmane.comp.lib.gnustep.general/33167

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

[Yavor Doganov]

Follow-up Comment #17, bug #30766 (project gnustep):

Looking at the diff, the only thing that comes to (my) mind is some oddity
with hiding the pthread stuff (hppa has the largest size of pthread_mutex_t --
48 -- but this shouldn't be a problem AFAICS), or the NSRunLoop change. 
Should I ask to revert either of them and repeat the test?

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

[Yavor Doganov]

Follow-up Comment #16, bug #30766 (project gnustep):

Final results:

- r28611 is ok
- r28612 didn't compile [1]
- r28613 exposes the bug

[1]
NSLock.m: In function ‘-[NSCondition lockBeforeDate:]’:
NSLock.m:247: warning: passing argument 1 of ‘pthread_mutex_trylock’
from
incompatible pointer type
/usr/include/pthread.h:732: note: expected ‘union pthread_mutex_t *’ but
argument is of type ‘struct pthread_mutex_t *’
NSLock.m: At top level:
NSLock.m:344: warning: cast increases required alignment of target type
NSLock.m:344: warning: cast increases required alignment of target type
NSLock.m:344: warning: cast increases required alignment of target type
NSLock.m:344: warning: cast increases required alignment of target type
NSLock.m:344: warning: cast increases required alignment of target type
NSLock.m:344: warning: cast increases required alignment of target type
NSLock.m:344: warning: cast increases required alignment of target type
NSLock.m:344: warning: cast increases required alignment of target type
make[4]: *** [obj/libgnustep-base.obj/NSLock.m.o] Error 1
make[3]: *** [internal-library-all_] Error 2
make[2]: *** [libgnustep-base.all.library.variables] Error 2
make[1]: *** [internal-all] Error 2
make: *** [internal-all] Error 2

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

[Yavor Doganov]

Follow-up Comment #15, bug #30766 (project gnustep):

Further narrowed down to -r28600:r28625 (continuing).

I asked on debian-hppa about some information for the switch from
Linuxthreads to NPTL on hppa -- I remember it was very hard, and there were
some odd details.  It may turn out to be a glibc bug (which explains why I
can't reproduce with glibc 2.7, which is using the old Linuxthreads).  Or
maybe not, so please try to investigate.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

[Yavor Doganov]

Follow-up Comment #14, bug #30766 (project gnustep):

First results from the bisect operation: r28600 good, r28700 bad.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

[Yavor Doganov]

Follow-up Comment #13, bug #30766 (project gnustep):

I asked the bug reporter to commence the bisection procedure, starting from
the tip (just in case), then narrowing between the last "good" r28586 (1.19.3)
and "bad" r30325 (1.20.0).

I'll followup here with the results as soon as I have them.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

[Richard Frith-Macdonald]

Follow-up Comment #12, bug #30766 (project gnustep):

I'm afraid there's little that those of us without hppa systems (like myself)
can do other than offer a bit of advice.

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.  

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

[Yavor Doganov]

Follow-up Comment #11, bug #30766 (project gnustep):

Here is another backtrace from a different program (test3.m) that doesn't use
NSProcessInfo:

Program received signal SIGABRT, Aborted.
0x40fc98ac in *__GI_raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:67
67  ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
in ../nptl/sysdeps/unix/sysv/linux/raise.c
#0  0x40fc98ac in *__GI_raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:67
#1  0x40fce258 in *__GI_abort () at abort.c:92
#2  0x4100f084 in __malloc_assert (assertion=,
file=, line=, function=) at malloc.c:352
#3  0x41012e74 in sYSMALLOc (av=0x410f29dc, bytes=24) at malloc.c:3094
#4  _int_malloc (av=0x410f29dc, bytes=24) at malloc.c:4747
#5  0x41015588 in *__GI___libc_malloc (bytes=24) at malloc.c:3661
#6  0x40b88538 in objc_malloc (size=11523) at
/build/buildd-gcc-4.4_4.4.4-8-hppa-mim0Jd/gcc-4.4-4.4.4/src/libobjc/misc.c:89
#7  0x4089cd00 in default_malloc (zone=, size=11523) at
NSZone.m:124
#8  0x4089c508 in NSZoneMalloc (zone=, size=11523) at
NSZone.m:2013
#9  0x4089ced0 in NSZoneCalloc (zone=0x2d03, elems=,
bytes=6) at NSZone.m:1964
#10 0x407b3aec in GSIMapResize (self=0x3cb88, _cmd=,
observer=, selector=, name=0x50118,
object=0x0) at ../Headers/Additions/GNUstepBase/GSIMap.h:741
#11 GSIMapRightSizeMap (self=0x3cb88, _cmd=,
observer=, selector=, name=0x50118,
object=0x0) at ../Headers/Additions/GNUstepBase/GSIMap.h:770
#12 GSIMapInitWithZoneAndCapacity (self=0x3cb88, _cmd=,
observer=, selector=, name=0x50118,
object=0x0) at ../Headers/Additions/GNUstepBase/GSIMap.h:1218
#13 mapNew (self=0x3cb88, _cmd=, observer=, selector=, name=0x50118, object=0x0) at
NSNotificationCenter.m:326
#14 -[NSNotificationCenter addObserver:selector:name:object:] (self=0x3cb88,
_cmd=, observer=, selector=, name=0x50118, object=0x0) at NSNotificationCenter.m:786
#15 0x4085b944 in +[NSTimeZone initialize] (self=,
_cmd=) at NSTimeZone.m:1297
#16 0x40b8bd44 in __objc_send_initialize (class=0x409f686c) at
/build/buildd-gcc-4.4_4.4.4-8-hppa-mim0Jd/gcc-4.4-4.4.4/src/libobjc/sendmsg.c:386
#17 0x40b8c200 in __objc_init_install_dtable (receiver=0x409f686c, op=) at
/build/buildd-gcc-4.4_4.4.4-8-hppa-mim0Jd/gcc-4.4-4.4.4/src/libobjc/sendmsg.c:328
#18 objc_msg_lookup (receiver=0x409f686c, op=) at
/build/buildd-gcc-4.4_4.4.4-8-hppa-mim0Jd/gcc-4.4-4.4.4/src/libobjc/sendmsg.c:234
#19 0x406e73d4 in +[NSCalendarDate initialize] (self=,
_cmd=) at NSCalendarDate.m:356
#20 0x40b8bd44 in __objc_send_initialize (class=0x409b3e98) at
/build/buildd-gcc-4.4_4.4.4-8-hppa-mim0Jd/gcc-4.4-4.4.4/src/libobjc/sendmsg.c:386
#21 0x40b8c200 in __objc_init_install_dtable (receiver=0x409b3e98, op=) at
/build/buildd-gcc-4.4_4.4.4-8-hppa-mim0Jd/gcc-4.4-4.4.4/src/libobjc/sendmsg.c:328
#22 objc_msg_lookup (receiver=0x409b3e98, op=) at
/build/buildd-gcc-4.4_4.4.4-8-hppa-mim0Jd/gcc-4.4-4.4.4/src/libobjc/sendmsg.c:234
#23 0x40736fe4 in +[NSDate initialize] (self=0x409be69c, _cmd=) at NSDate.m:137
#24 0x40b8bd44 in __objc_send_initialize (class=0x409be69c) at
/build/buildd-gcc-4.4_4.4.4-8-hppa-mim0Jd/gcc-4.4-4.4.4/src/libobjc/sendmsg.c:386
#25 0x40b8c200 in __objc_init_install_dtable (receiver=0x409be69c, op=) at
/build/buildd-gcc-4.4_4.4.4-8-hppa-mim0Jd/gcc-4.4-4.4.4/src/libobjc/sendmsg.c:328
#26 objc_msg_lookup (receiver=0x409be69c, op=) at
/build/buildd-gcc-4.4_4.4.4-8-hppa-mim0Jd/gcc-4.4-4.4.4/src/libobjc/sendmsg.c:234
#27 0x40887ef0 in +[NSUserDefaults initialize] (self=,
_cmd=) at NSUserDefaults.m:298
#28 0x40b8bd44 in __objc_send_initialize (class=0x40a032fc) at
/build/buildd-gcc-4.4_4.4.4-8-hppa-mim0Jd/gcc-4.4-4.4.4/src/libobjc/sendmsg.c:386
#29 0x40b8c200 in __objc_init_install_dtable (receiver=0x40a032fc, op=) at
/build/buildd-gcc-4.4_4.4.4-8-hppa-mim0Jd/gcc-4.4-4.4.4/src/libobjc/sendmsg.c:328
#30 objc_msg_lookup (receiver=0x40a032fc, op=) at
/build/buildd-gcc-4.4_4.4.4-8-hppa-mim0Jd/gcc-4.4-4.4.4/src/libobjc/sendmsg.c:234
#31 0x40889270 in GSPrivateDefaultsFlag (type=GSLogSyslog) at
NSUserDefaults.m:2141
#32 0x407ad414 in NSLogv (format=0x127cc, args=0xfaf0169c) at NSLog.m:305
#33 0x407ada5c in NSLog (format=) at NSLog.m:252
#34 0x0001095c in -[NCTest notified:] (self=0x511c8, _cmd=0x128e0,
notif=0x51450) at test.m:13
#35 0x407b4424 in -[NSNotificationCenter _postAndRelease:] (self=0x3cb88,
_cmd=, notification=0x51450) at
NSNotificationCenter.m:1161
#36 0x407b11c0 in -[NSNotificationCenter
postNotificationName:object:userInfo:] (self=0x3cb88, _cmd=, name=0x409d62a8, object=0x35e08, info=0x0) at
NSNotificationCenter.m:1220
#37 0x407b0c6c in -[NSNotificationCenter postNotificationName:object:]
(self=0x3cb88, _cmd=, name=,
object=) at NSNotificationCenter.m:1200
#38 0x00010d50 in main () at test.m:36

(file #21251)
___

Additional Item Attachment:

File name: test3.mSize:0 KB


___

Reply to this item at:

  

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

[Yavor Doganov]

Follow-up Comment #10, bug #30766 (project gnustep):

I could not reproduce with gcc-4.4.4 + Debian patches, but that was on a
Debian Lenny machine.  Apparently only modern systems (new glibc, etc.) are
affected.

FYI, the following tests were performed on paer.debian.org, in a Debian
unstable chroot (sources attached):

Good:
test2.m (very simple GNUstep tool)
test-0.1.tar.gz (simple plain Objective-C program)

Bad:
test1.m (simple GNUstep tool using NSProcessInfo)

Base 1.20.1 built with GCC 4.3 (no native objc exceptions) also exposes the
bug.

(file #21246, file #21247, file #21248)
___

Additional Item Attachment:

File name: test1.mSize:0 KB
File name: test-0.1.tar.gzSize:68 KB
File name: test2.mSize:0 KB


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

[Yavor Doganov]

Follow-up Comment #9, bug #30766 (project gnustep):

FYI: I asked the original bug reporter to try 1.20.0; it still fails in the
same way.

I'll wait for my tests with a debianized gcc before doing anything else.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

[Yavor Doganov]

Follow-up Comment #8, bug #30766 (project gnustep):

>> Base 1.19.3 runs fine, so I guess they can be ruled out right
>> away.

> Unfortunately not as it's perfectly possible for some code to 
> trigger bugs in the compiler or runtime that other code does
> not trigger.

Right, I was thinking along the same line as well right after I sent the
message.  Today I got an account on the GCC compile farm
(http://gcc.gnu.org/wiki/CompileFarm) and could not reproduce the problem on
gcc61.fsffrance.org with Base 1.20.1, compiled with manually built GCC 4.4.4. 
I'm now building the same version of GCC + Debian-specific patches; if it
exposes the problem, I'll pass the hot potato to the Debian GCC maintainers. 
But we'll still need some workaround to get functional GNUstep on this
architecture.

> My only new idea on how to proceed is to try a bisection
> of the code changes since 1.19.3.

Yes, I was going to do exactly this if I was fortunate enough to reproduce.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

[Fred Kiefer]

Follow-up Comment #7, bug #30766 (project gnustep):

Thank you for the reference to the build output. 

My only new idea on how to proceed is to try a bisection of the code changes
since 1.19.3. You should start of by testing 1.20.0 and then use SVN versions
of the code in between.

We have too much that changed since 1.19.3 to tell otherwise. The whole
thread and lock handling was completely rewritten, the interaction with the
Objective-C runtime was reimplemented, so were NSInvocation and NSNumber. We
enabled 64 bit NSInteger support and so much more.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

[Richard Frith-Macdonald]

Follow-up Comment #6, bug #30766 (project gnustep):

>> The later two could be ruled out by running a non GNUstep 
>> Objective-C program compile don this machine. 
>
> Base 1.19.3 runs fine, so I guess they can be ruled out right away. 

Unfortunately not as it's perfectly possible for some code to trigger bugs in
the compiler or runtime that other code does not trigger.

>> Next you should check which of the different cases for argument 
>> inspection applies in your environment. 
>
>I don't have access to Debian's porter machines, but I can ask the bug
reporter to >perform whatever tests are needed. 

I would guess that, in the absence of something like valgrind which will
report memory problems, what's needed is actually to run the program under gdb
and step through to find where something goes wrong.

One thing ... in the original stackdump reported I see this:

> #14 0x409e5304 in pathSeps () at NSString.m:268

but line 268 should only be executed if using mswindows style path separators
... which suggests that memory must already have been corrupted by the time
this point was reached.



___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

[Yavor Doganov]

Follow-up Comment #5, bug #30766 (project gnustep):

Here is some information about this architecture, in case it can be of help.

Type size:
short 2
int   4 
long  4
long long 8
float 4
double8
long double   8
data pointer  4

endianness: big
unaligned access not OK
char signedness: s
stack grows up (the only platform where this is so)

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

[Yavor Doganov]

Follow-up Comment #4, bug #30766 (project gnustep):

> The later two could be ruled out by running a non GNUstep 
> Objective-C program compile don this machine.

Base 1.19.3 runs fine, so I guess they can be ruled out right away.

> Next you should check which of the different cases for argument
> inspection applies in your environment.

I don't have access to Debian's porter machines, but I can ask the bug
reporter to perform whatever tests are needed.

> Do you get any compiler warnings for GNUstep base?

Yes, many, particularly "cast increases required alignment of target type". 
See attached file warnings.txt; full build log available at
https://buildd.debian.org/fetch.cgi?pkg=gnustep-base&arch=hppa&ver=1.20.1-2&stamp=1281448914&file=log&as=raw.

(file #21236)
___

Additional Item Attachment:

File name: warnings.txt   Size:18 KB


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

[Fred Kiefer]

Follow-up Comment #3, bug #30766 (project gnustep):

Not having valgrind is really bad.
The next thing that you could try to do is pin down where the problem comes
from. I think it can only be one of three things, either GNUstep base has some
serious problem (Most likely in NSProcessInfo where we try to gather the
process arguments), in the libobjc or in the compiler itself. 
The later two could be ruled out by running a non GNUstep Objective-C program
compile don this machine. 
Next you should check which of the different cases for argument inspection
applies in your environment.
There is one more point: Do you get any compiler warnings for GNUstep base?
If so, please report them here.


___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

[Yavor Doganov]

Follow-up Comment #2, bug #30766 (project gnustep):

This happens with all programs (gdnc, pl2link, etc...)  It was discovered
while building gnustep-gui which invokes the just built make_services during
the build process.

> Could you please run this program under valgrind?

Valgrind is not available on this platform.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

[Fred Kiefer]

Update of bug #30766 (project gnustep):

 Assigned to:None => FredKiefer 

___

Follow-up Comment #1:

Does this only happen with make_services or are all GNUstep programs
affected? There weren't that much changes to make_services in the last few
years. Could you try to run any of the tools that come with base, just to see
whether it is really a base problem or if gui has any play in this.

>From searching the internet for issues with sYSMALLOc, I would say that this
back trace is caused by some memory corruption at another place. But we are
here almost at the beginning of the application.
Could you please run this program under valgrind? This should help to pin
down the real issue behind this problem.


___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #30766] Serious problems on hppa -- all programs abort with malloc assertion failure

[Yavor Doganov]

URL:
  

 Summary: Serious problems on hppa -- all programs abort with
malloc assertion failure
 Project: GNUstep
Submitted by: yavor
Submitted on: Fri 13 Aug 2010 12:41:01 PM EEST
Category: Base/Foundation
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

It looks like 1.20.1 is severely broken on hppa-linux-gnu; see an example
backtrace below.  1.19.3 appears to work fine, so my conclusion is that this
is not due to anticipated toolchain problems on that platform.  Unfortunately,
this is a blocker for the ongoing GNUstep transition in Debian because hppa is
a release architecture.

Downstream bug report:


Starting program: /home/dannf/gnustep-gui-0.18.0/Tools/obj/make_services
--help
[Thread debugging using libthread_db enabled]
make_services: malloc.c:3097: sYSMALLOc: Assertion `(old_top == (((mbinptr)
(((char *) &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct
malloc_chunk, fd && old_size == 0) || ((unsigned long) (old_size) >=
(unsigned long)__builtin_offsetof (struct malloc_chunk, fd_nextsize))+((2
* (sizeof(size_t))) - 1)) & ~((2 * (sizeof(size_t))) - 1))) &&
((old_top)->size & 0x1) && ((unsigned long)old_end & pagemask) == 0)' failed.

Program received signal SIGABRT, Aborted.
0x404a98ac in *__GI_raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:67
67 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
   in ../nptl/sysdeps/unix/sysv/linux/raise.c
(gdb) thread apply all bt full

Thread 1 (Thread 0x40004b80 (LWP 20173)):
#0  0x404a98ac in *__GI_raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:67
__r25 = 20173
__res = 
__r19 = 
__r24 = 6
__r26 = 
pd = 0x40004b80
pid = 20173
selftid = 20173
res = 
#1  0x404ae258 in *__GI_abort () at abort.c:92
act = {__sigaction_handler = {sa_handler = ,
sa_sigaction = }, sa_flags = 4210038464, sa_mask =
{__val = {4210038416, 168, 1079839352, 1079839352, 1078825987, 1078825987,
951080, 946692, 4294967295, 946708, 1079839352, 1079830408, 288248, 372512,
18, 1086146538, 372280, 132, 1079839352, 1079839352, 1079847388, 1078941067,
951080, 946692, 4294967295, 946708, 1077441636, 295, 1079837304, 1079837304,
1079837304, 152}}}
sigs = {__val = {32, 0 }}
#2  0x404ef084 in __malloc_assert (assertion=,
file=, line=, function=) at malloc.c:352
No locals.
#3  0x404f2e74 in sYSMALLOc (av=0x405d29dc, bytes=344) at malloc.c:3094
snd_brk = 
front_misalign = 
remainder = 
tried_mmap = false
old_size = 
size = 
old_end = 0x5dc50 ""
correction = 
end_misalign = 
aligned_brk = 
p = 
pagemask = 4095
#4  _int_malloc (av=0x405d29dc, bytes=344) at malloc.c:4747
p = 
iters = 
nb = 352
idx = 
bin = 
victim = 0x5dc50
size = 0
victim_index = 
remainder = 
remainder_size = 
block = 4
bit = 
map = 
fwd = 
bck = 
errstr = 
__func__ = "_int_malloc"
#5  0x404f5588 in *__GI___libc_malloc (bytes=344) at malloc.c:3661
ar_ptr = 0x405d29dc
victim = 0x56
__func__ = "__libc_malloc"
#6  0x40379538 in objc_malloc (size=20173) at
/build/buildd-gcc-4.4_4.4.4-8-hppa-mim0Jd/gcc-4.4-4.4.4/src/libobjc/misc.c:89
res = 
#7  0x4037adec in sarray_lazy_copy (oarr=0x45840) at
/build/buildd-gcc-4.4_4.4.4-8-hppa-mim0Jd/gcc-4.4-4.4.4/src/libobjc/sarray.c:507
num_indices = 86
#8  0x4037c7d8 in __objc_install_dispatch_table_for_class (class=0x40b5d3c4)
at
/build/buildd-gcc-4.4_4.4.4-8-hppa-mim0Jd/gcc-4.4-4.4.4/src/libobjc/sendmsg.c:442
super = 0x40b83030
#9  0x4037c868 in __objc_install_dispatch_table_for_class (class=0x40b5d19c)
at
/build/buildd-gcc-4.4_4.4.4-8-hppa-mim0Jd/gcc-4.4-4.4.4/src/libobjc/sendmsg.c:432
super = 0x40b5d3c4
#10 0x4037d1a0 in __objc_init_install_dtable (receiver=0x1fa68, op=) at
/build/buildd-gcc-4.4_4.4.4-8-hppa-mim0Jd/gcc-4.4-4.4.4/src/libobjc/sendmsg.c:313
No locals.
#11 objc_msg_lookup (receiver=0x1fa68, op=) at
/build/buildd-gcc-4.4_4.4.4-8-hppa-mim0Jd/gcc-4.4-4.4.4/src/libobjc/sendmsg.c:234
result = 
#12 0x4096bb18 in +[NSObject new] (self=0x40b5d19c, _cmd=) at NSObject.m:1192
No locals.
#13 0x4089c3b4 in +[NSCharacterSet characterSetWithCharactersInString:]
(self=, _cmd=, aString=) at NSCharacterSet.m:802
No locals.
#14 0x409e5304 in pathSeps () at NSString.m:268
wPathSeps = 0x0
uPathSeps = 0x0
rPathSeps = 0x0
#15 0x409e76e8 in -[NSString lastPathComp