bugGNUstep - Bugs: bug #30766, Serious problems on hppa -- all...

Group
 
 

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

Submitter:  Yavor Doganov <yavor>
Submitted:  Fri 13 Aug 2010 09:41:01 AM UTC
   
 
Category:  Base/Foundation Severity:  3 - Normal
Item Group:  Bug Status:  Ready For Test
Privacy:  Public Assigned to:  CaS
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sat 05 Mar 2011 03:17:46 PM UTC, comment #28: 

No update after several months.

Richard Frith-Macdonald <CaS>
Group Member
Mon 23 Aug 2010 10:31:32 PM UTC, comment #27: 

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

Riccardo Mottola <rmottola>
Group Member
Mon 23 Aug 2010 04:13:40 PM UTC, comment #26: 

on windows the patch appears to work.

Riccardo Mottola <rmottola>
Group Member
Mon 23 Aug 2010 12:58:47 PM UTC, comment #25: 

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

(file #21281)

Yavor Doganov <yavor>
Mon 23 Aug 2010 09:35:38 AM UTC, comment #24: 

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

Riccardo Mottola <rmottola>
Group Member
Mon 23 Aug 2010 09:19:13 AM UTC, comment #23: 

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

Yavor Doganov <yavor>
Mon 23 Aug 2010 08:14:25 AM UTC, comment #22: 

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

Riccardo Mottola <rmottola>
Group Member
Fri 20 Aug 2010 12:06:12 PM UTC, comment #21: 

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!

Yavor Doganov <yavor>
Thu 19 Aug 2010 09:14:37 PM UTC, comment #20: 

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

Richard Frith-Macdonald <CaS>
Group Member
Thu 19 Aug 2010 07:16:41 PM UTC, comment #19: 

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."

Yavor Doganov <yavor>
Thu 19 Aug 2010 05:37:41 PM UTC, comment #18: 

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

Yavor Doganov <yavor>
Thu 19 Aug 2010 04:39:56 PM UTC, comment #17: 

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?

Yavor Doganov <yavor>
Thu 19 Aug 2010 03:57:35 PM UTC, comment #16: 

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

Yavor Doganov <yavor>
Thu 19 Aug 2010 02:33:17 PM UTC, comment #15: 

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.

Yavor Doganov <yavor>
Thu 19 Aug 2010 01:47:10 PM UTC, comment #14: 

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

Yavor Doganov <yavor>
Thu 19 Aug 2010 09:11:03 AM UTC, comment #13: 

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.

Yavor Doganov <yavor>
Thu 19 Aug 2010 08:20:59 AM UTC, comment #12: 

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.

Richard Frith-Macdonald <CaS>
Group Member
Wed 18 Aug 2010 03:56:09 PM UTC, comment #11: 

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=<value optimized out>, file=<value optimized out>, line=<value optimized out>, function=<value optimized out>) 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=<value optimized out>, size=11523) at NSZone.m:124
#8  0x4089c508 in NSZoneMalloc (zone=<value optimized out>, size=11523) at NSZone.m:2013
#9  0x4089ced0 in NSZoneCalloc (zone=0x2d03, elems=<value optimized out>, bytes=6) at NSZone.m:1964
#10 0x407b3aec in GSIMapResize (self=0x3cb88, _cmd=<value optimized out>, observer=<value optimized out>, selector=<value optimized out>, name=0x50118, object=0x0) at ../Headers/Additions/GNUstepBase/GSIMap.h:741
#11 GSIMapRightSizeMap (self=0x3cb88, _cmd=<value optimized out>, observer=<value optimized out>, selector=<value optimized out>, name=0x50118, object=0x0) at ../Headers/Additions/GNUstepBase/GSIMap.h:770
#12 GSIMapInitWithZoneAndCapacity (self=0x3cb88, _cmd=<value optimized out>, observer=<value optimized out>, selector=<value optimized out>, name=0x50118, object=0x0) at ../Headers/Additions/GNUstepBase/GSIMap.h:1218
#13 mapNew (self=0x3cb88, _cmd=<value optimized out>, observer=<value optimized out>, selector=<value optimized out>, name=0x50118, object=0x0) at NSNotificationCenter.m:326
#14 -[NSNotificationCenter addObserver:selector:name:object:] (self=0x3cb88, _cmd=<value optimized out>, observer=<value optimized out>, selector=<value optimized out>, name=0x50118, object=0x0) at NSNotificationCenter.m:786
#15 0x4085b944 in +[NSTimeZone initialize] (self=<value optimized out>, _cmd=<value optimized out>) 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=<value optimized out>) 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=<value optimized out>) 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=<value optimized out>, _cmd=<value optimized out>) 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=<value optimized out>) 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=<value optimized out>) 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=<value optimized out>) 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=<value optimized out>) 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=<value optimized out>) 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=<value optimized out>, _cmd=<value optimized out>) 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=<value optimized out>) 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=<value optimized out>) 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=<value optimized out>) 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=<value optimized out>, notification=0x51450) at NSNotificationCenter.m:1161
#36 0x407b11c0 in -[NSNotificationCenter postNotificationName:object:userInfo:] (self=0x3cb88, _cmd=<value optimized out>, name=0x409d62a8, object=0x35e08, info=0x0) at NSNotificationCenter.m:1220
#37 0x407b0c6c in -[NSNotificationCenter postNotificationName:object:] (self=0x3cb88, _cmd=<value optimized out>, name=<value optimized out>, object=<value optimized out>) at NSNotificationCenter.m:1200
#38 0x00010d50 in main () at test.m:36

(file #21251)

Yavor Doganov <yavor>
Tue 17 Aug 2010 09:53:05 PM UTC, comment #10: 

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)

Yavor Doganov <yavor>
Mon 16 Aug 2010 07:38:27 PM UTC, comment #9: 

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.

Yavor Doganov <yavor>
Mon 16 Aug 2010 06:26:06 PM UTC, comment #8: 


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

Yavor Doganov <yavor>
Mon 16 Aug 2010 05:54:26 PM UTC, comment #7: 

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.

Fred Kiefer <FredKiefer>
Group Member
Mon 16 Aug 2010 05:38:33 PM UTC, comment #6: 


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


Richard Frith-Macdonald <CaS>
Group Member
Mon 16 Aug 2010 04:47:09 PM UTC, comment #5: 

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
double        8
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)

Yavor Doganov <yavor>
Mon 16 Aug 2010 04:10:48 PM UTC, comment #4: 


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

Yavor Doganov <yavor>
Mon 16 Aug 2010 03:10:41 PM UTC, comment #3: 

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.

Fred Kiefer <FredKiefer>
Group Member
Sun 15 Aug 2010 05:55:54 PM UTC, comment #2: 

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.

Yavor Doganov <yavor>
Sat 14 Aug 2010 05:02:09 PM UTC, 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.

Fred Kiefer <FredKiefer>
Group Member
Fri 13 Aug 2010 09:41:01 AM UTC, original submission:  

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:
<http://bugs.debian.org/592751>

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 = <value optimized out>
        __r19 = <value optimized out>
        __r24 = 6
        __r26 = <value optimized out>
        pd = 0x40004b80
        pid = 20173
        selftid = 20173
        res = <value optimized out>
#1  0x404ae258 in *__GI_abort () at abort.c:92
        act = {__sigaction_handler = {sa_handler = <error reading variable>, sa_sigaction = <error reading variable>}, 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 <repeats 31 times>}}
#2  0x404ef084 in __malloc_assert (assertion=<value optimized out>, file=<value optimized out>, line=<value optimized out>, function=<value optimized out>) at malloc.c:352
No locals.
#3  0x404f2e74 in sYSMALLOc (av=0x405d29dc, bytes=344) at malloc.c:3094
        snd_brk = <value optimized out>
        front_misalign = <value optimized out>
        remainder = <value optimized out>
        tried_mmap = false
        old_size = <value optimized out>
        size = <value optimized out>
        old_end = 0x5dc50 ""
        correction = <value optimized out>
        end_misalign = <value optimized out>
        aligned_brk = <value optimized out>
        p = <value optimized out>
        pagemask = 4095
#4  _int_malloc (av=0x405d29dc, bytes=344) at malloc.c:4747
        p = <value optimized out>
        iters = <value optimized out>
        nb = 352
        idx = <value optimized out>
        bin = <value optimized out>
        victim = 0x5dc50
        size = 0
        victim_index = <value optimized out>
        remainder = <value optimized out>
        remainder_size = <value optimized out>
        block = 4
        bit = <value optimized out>
        map = <value optimized out>
        fwd = <value optimized out>
        bck = <value optimized out>
        errstr = <value optimized out>
        _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 = <value optimized out>
#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=<value optimized out>) 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=<value optimized out>) at /build/buildd-gcc-4.4_4.4.4-8-hppa-mim0Jd/gcc-4.4-4.4.4/src/libobjc/sendmsg.c:234
        result = <value optimized out>
#12 0x4096bb18 in +[NSObject new] (self=0x40b5d19c, _cmd=<value optimized out>) at NSObject.m:1192
No locals.
#13 0x4089c3b4 in +[NSCharacterSet characterSetWithCharactersInString:] (self=<value optimized out>, _cmd=<value optimized out>, aString=<value optimized out>) at NSCharacterSet.m:802
No locals.
#14 0x409e5304 in pathSeps () at NSString.m:268
        wPathSeps = 0x0
        uPathSeps = 0x0
        rPathSeps = 0x0
#15 0x409e76e8 in -[NSString lastPathComponent] (self=0x5cc50, _cmd=<value optimized out>) at NSString.m:3427
        l = 54
        range = {location = 1086209352, length = 269576}
        i = 1
#16 0x409a5a64 in _gnu_process_args (argc=2, argv=0x42bd0, env=0x41d08) at NSProcessInfo.m:287
        i = <value optimized out>
#17 0x409a6324 in +[NSProcessInfo initialize] (self=<value optimized out>, _cmd=<value optimized out>) at NSProcessInfo.m:852
No locals.
#18 0x4037cd44 in __objc_send_initialize (class=0x40b8cbe0) at /build/buildd-gcc-4.4_4.4.4-8-hppa-mim0Jd/gcc-4.4-4.4.4/src/libobjc/sendmsg.c:386
        op = 0x0
        imp = 0x400c0440 <_pthread_cleanup_pop_restore>
        method_list = 0x8
        _PRETTY_FUNCTION_ = "__objc_send_initialize"
#19 0x4037d200 in __objc_init_install_dtable (receiver=0x40b8cbe0, op=<value optimized out>) at /build/buildd-gcc-4.4_4.4.4-8-hppa-mim0Jd/gcc-4.4-4.4.4/src/libobjc/sendmsg.c:328
No locals.
#20 objc_msg_lookup (receiver=0x40b8cbe0, op=<value optimized out>) at /build/buildd-gcc-4.4_4.4.4-8-hppa-mim0Jd/gcc-4.4-4.4.4/src/libobjc/sendmsg.c:234
        result = <value optimized out>
#21 0x00014870 in main (argc=<value optimized out>, argv=<value optimized out>, env_c=<value optimized out>) at make_services.m:120
        data = <value optimized out>
        proc = <value optimized out>
        mgr = 0x59f90
        usrRoot = 0x40000560
        str = <value optimized out>
        index = <value optimized out>

Yavor Doganov <yavor>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #21281:  AC_CHECK_ALIGNOF.patch added by yavor (887B - text/x-patch)
file #21251:  test3.m added by yavor (1016B - application/octet-stream)
file #21247:  test-0.1.tar.gz added by yavor (69KiB - application/x-gzip)
file #21248:  test2.m added by yavor (191B - application/octet-stream)
file #21246:  test1.m added by yavor (584B - application/octet-stream)
file #21236:  warnings.txt added by yavor (19KiB - text/plain - Compilation warnings on hppa)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rmottola (Posted a comment)
  • -email is unavailable- added by CaS (Posted a comment)
  • -email is unavailable- added by FredKiefer (Posted a comment)
  • -email is unavailable- added by yavor (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 11 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2011-03-05 CaS Open/ClosedIn Test Closed
    2010-08-29 FredKiefer StatusNone Ready For Test
        Assigned toFredKiefer CaS
        Open/ClosedOpen In Test
    2010-08-23 yavor Attached File- Added AC_CHECK_ALIGNOF.patch, #21281
    2010-08-18 yavor Attached File- Added test3.m, #21251
    2010-08-17 yavor Attached File- Added test1.m, #21246
        Attached File- Added test-0.1.tar.gz, #21247
        Attached File- Added test2.m, #21248
    2010-08-16 yavor Attached File- Added warnings.txt, #21236
    2010-08-14 FredKiefer Assigned toNone FredKiefer

    Back to the top

    Powered by Savane 3.13-cf05.
    Corresponding source code