bus error on pthread_exit(), HP-UX 11i, aCC 3.37

[James Parker_2]

I am getting a bus error on a call to pthread_exit(), from the top level of a completing thread. The code is compiled with aCC 3.37 (32-bit), and is executing on an HP 9000/785, running HP-UX11i.

The problem is at pthread_exit()+316 (via gdb), although I suspect it is based on the call at pthread_exit()+308:

b,l 0x7ad29b80 <$$dyncall_external>, %r31

since <$$dyncall_external> shows up on the stack. This is reported as an unnamed function in gdb, which at its first line (which causes the bus error) has:

ldw 2(%r22),%r19

r22 is zero, which leads to a load from address 0x2, thus causing the bus error.

Any ideas as to what the underlying cause could be?

Thanks,

James Parker
CSG Systems

[Michael Steele_2]

Could you copy and paste the exact error as it appears. Where is this appearing? When you compile and it aborts? In syslog.log?

What's your shared memory indicate?

ipcs -moba

Anything associated to these processes to remove?

ipcrm -m id

Note the NATTACH field:

http://docs.hp.com/cgi-bin/fsearch/framedisplay?top=/hpux/onlinedocs/B2355-90128/B2355-90128_top.html&con=/hpux/onlinedocs/B2355-90128/00/01/136-con.html&toc=/hpux/onlinedocs/B2355-90128/00/01/136-toc.html&searchterms=ipcs&queryid=20030328-150612

[James Parker_2]

> Could you copy and paste the exact error as it appears. Where is this appearing? When you compile and it aborts? In syslog.log?

The text I put in was the disassembled code from the executable and core dump, using gdb/wdb. The syslog.log file reports nothing of interest (no activities during this timeframe).

> What's your shared memory indicate?

There are about 3.5MB of shared memory, all created by root (all but one owned by root; the other by www). We are not using shared memory currently, but do have ~150MB of application memory mapped files, MAP_SHARED.

Jim

[James Parker_2]

I've found the problem; it was a lower-level error with an unmatched pthread_cleanup_push() call. A function was pushed, but never popped; the argument to the function was a "this" pointer for an object which was on the thread stack. When pthread_exit() was called, it (as documented) attempted to execute the cleanup function (which may be the unnamed function reported by gdb); however, its argument was no longer valid, and it was being used to locate the function to be called; the result was a call referenced from a NULL pointer.

The dyncall_extern reference was likely the result of this function being in a dynamic library; this was arguably invoked to find the actual (now unavailable function) which caused the reference off a NULL pointer, a badly aligned address (if not for the alignment error this would have caused a SEGV) and the bus error.

Jim