PR_GetThreadID() fails with SEGV

[Jon Leighton]

I'm using NSPR 4.8 on Solaris 5.10, and OpenSolaris 5.11, and if I call
PR_GetThreadID(PR_GetCurrentThread()), it fails with SEGV. The same
code works fine on a number of other platforms. Is there an issue with
PR_GetThreadID() on Solaris/OpenSolaris, or something different I need
to do? Thanks for any help.

- Jon

[Wan-Teh Chang]

PR_GetThreadID() is a deprecated function because its return type
PRUint32 is too small to hold a native thread ID on some platforms
(if pthread_t is 64-bit).

But that means the problem should be a truncation of the native
thread ID, not a crash due to SEGV.

Since I don't have access to Solaris, I don't know what the problem
is. I inspected the source code and didn't see anything wrong or
Solaris-specific.

Wan-Teh

[Jon Leighton]

Wan-Teh Chang wrote:
> On Fri, Jun 12, 2009 at 7:17 PM, Jon Leighton<leig...@cis.udel.edu> wrote:
>> I'm using NSPR 4.8 on Solaris 5.10, and OpenSolaris 5.11, and if I call
>> PR_GetThreadID(PR_GetCurrentThread()), it fails with SEGV. The same code
>> works fine on a number of other platforms. Is there an issue with
>> PR_GetThreadID() on Solaris/OpenSolaris, or something different I need to
>> do? Thanks for any help.
>
> PR_GetThreadID() is a deprecated function because its return type
> PRUint32 is too small to hold a native thread ID on some platforms
> (if pthread_t is 64-bit).

Thanks Wan-Teh. Is there a new NSPR function to replace
PR_GetThreadID(), or should I just make due without?

- Jon

[Wan-Teh Chang]

On Sat, Jun 13, 2009 at 7:54 PM, Jon Leighton<leig...@cis.udel.edu> wrote:
>
> Thanks Wan-Teh.  Is there a new NSPR function to replace PR_GetThreadID(),
> or should I just make due without?

You should make do without PR_GetThreadID().
The closest thing is PR_GetCurrentThread(), which
returns a pointer rather than an integer.

You can also easily write your own function that
returns the native thread ID. You do need to make
a non-portable assumption that pthread_t is either
an integer or a pointer. The POSIX threads standard
allows pthread_t to be a struct, but in practice it is
almost always an integer or a pointer.

Wan-Teh

[Julien R Pierre - Sun Microsystems]

Jon,

I just tried the following on Solaris 10 x86 (32 bits). I experienced no
problem.

PRThread* prt = PR_GetCurrentThread();
PRUint32 tid;
tid = PR_GetThreadID(prt);
printf("Thread id : %d.\n", tid);

Please provide a crash stack. Even for a deprecated function, I would
not expect a crash. Are you passing a valid PRThread* pointer ?

[Jonathan Leighton]

Hi Julien -

I haven't yet tried to create a simple case where this fails, but where
I ran into the problem was in NSPR 4.8's socket.c test code. Line 501 is:

DPRINTF(("TCP_Server: Created Serve_Client = 0x%lx\n", t));

If I replace "t" with "PR_GetThreadID(t)" I get a SEGV on line 1097 of
ptthread.c. I found this to happen in Solaris 5.10 and OpenSolaris
5.11, but not in FreeBSD 7.2, Linux 2.6.28, or Mac OS X 10.5.6 (Intel).
Below is the output from dbx on Solarix 5.10.

- Jon

.
.
.
t@2 (l@2) signal SEGV (no mapping at the fault address) in
PR_GetThreadID at line 1097 in file "ptthread.c"
1097 return (PRUint32)thred->id; /* and I don't know what they
will do with it */
(dbx) where
current thread: t@2
=>[1] PR_GetThreadID(thred = 0xa), line 1097 in "ptthread.c"
[2] TCP_Server(arg = 0x8068af0), line 501 in "socket.c"
[3] _pt_root(arg = 0x806b408), line 228 in "ptthread.c"
[4] _thr_setup(0xfea50200), at 0xfeea7055
[5] _lwp_start(0x1, 0xfeb5efac, 0x8052a93, 0xa, 0x0, 0xfea50200), at
0xfeea7340
(dbx)

[Julien R Pierre - Sun Microsystems]

Jonathan,

Jonathan Leighton wrote:

Sorry for the late answer.

Your stack clearly shows an invalid PRThread pointer (thred = 0xa) being
passed to PR_GetThreadID.

I was able to reproduce this crash. Even when not setting the _debug_on
global variable, and simply fetching the thread id in a local like this,
in the TCP_Server function :

{
int tid = PR_GetThreadID(t);
}

It turns out there is some memory corruption in this test program.
The dbx "check -all" feature reports several "read from unallocated"
from multiple threads. I haven't narrowed down the cause of the
corruption exactly. Please file a bug on this.

[Jon Leighton]

Julien R Pierre - Sun Microsystems wrote:

Hi Julien -

Thanks for getting back to me. I just filed the bug report. The
problem seems to be that the create_new_thread() routine is returning a
thread pointer that only has local scope. It's easily fixed.

- Jon