c++/664: gcc 2.95/hpux generates code incompatible with threads

[colin_paton at agilent dot com]

>Number:         664
>Category:       c++
>Synopsis:       gcc 2.95/hpux generates code incompatible with threads
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    unassigned
>State:          open
>Class:          wrong-code
>Submitter-Id:   net
>Arrival-Date:   Fri Oct 20 07:26:00 PDT 2000
>Closed-Date:
>Last-Modified:
>Originator:     Colin Paton
>Release:        gcc version 2.95.2 19991024 (release)
>Organization:
>Environment:
HP-UX B.10.20 A 9000/778 (HP B-class B132 PA-RISC workstation)
>Description:
GCC appears to be generating code that is incompatible with HPUX threads. The problem occurs on both HP-UX 10.20 using the user-space CMA threads library and on HP-UX 11.00 using the kernel pthreads library.

Our code is causing segmentation faults at random times. We have noted two occurrances; one has occurred during a function return call and the other has occurred following a class method call.

Processor register r19 appears to hold an address that points to the value to be returned. When the problem shows investigation with the debugger appears to indicate that r19 holds the value 0. This causes the seg fault.

My theory (which may be incorrect!) is that registers r19-r26 are traditionally used only for function calls on PA-RISC architectures. I suspect that the HP thread libraries do not preserve the state of these registers during thread context switches.

gcc appears to be performing an optimisation in assuming that it can still use data in r19 following a function call. System calls (performed in other threads) seem to zero registers r19-26 - this is why r19 can sometimes become zeroed.

I do not know if it is possible to make gcc not use these registers, as they are possibly incompatible with the use of threads on hpux.

Unfortunately we cannot send our complete source code and I have not been able to create a simple subset of code that shows the problem. I did, however, come across an example posted to a mailing list describing a similar problem. The assembly language output in this problem bears a resemblance to our problem.

The enclosed attachment contains the following files:

gcc_test.cpp - the sample file from the mailing list that causes a reproducible crash.
command_output.txt - the verbose command output from the compile of gcc_test.cpp
gcc_test - the resultant excecutable.
gcc_test.s,gcc_test.ii,gcc_test.o - the resultant intermediate/object files
mailing_list_message.txt - the mailing list message pointing to a similar problem to our own, and which contains the source used for gcc_test.cpp
ObjectTransfer.cpp.excerpt - an excerpt from our source code
DebuggerOutput.txt - the debugger dissassembly of the code within ObjectTransfer.cpp.excerpt indicating where the problem occurs.

The same code compiles and runs with the HP supplied aCC version 1.21 compiler with no problems.

Many thanks,

Colin Paton

>How-To-Repeat:

>Fix:
The problem contained within ObjectTransfer::read() in the example file ObjectTransfer.cpp.excerpt can be fixed by adding an extra function call to prevent the r19-r26 optimisation problem:

* Move the Object* obj = rw->deserialize(*this) line into its own function.
* Uncomment the cout << "read object" line
* Change the order of thread creation so that threads are scheduled differently.

Although this is a threads problem we do not believe that the problem occurs due to unprotected data/thread race conditions. 
>Release-Note:
>Audit-Trail:
>Unformatted: