Summary:ASTERISK-02698: [patch] logger.c casts pthread_self() to long
Reporter:Edwin Groothuis (mavetju)Labels:
Date Opened:2004-10-27 23:27:35Date Closed:2008-01-15 15:12:29.000-0600
Versions:Frequency of
Environment:Attachments:( 0) asterisk::logger.c
Description:This is under Linux 2.6.5 (RedHat Fedora Core 2), my issue is with the negative numbers:

Oct 28 13:52:24 NOTICE[-167330896]: Rejected connect attempt from
Oct 28 13:53:35 NOTICE[-167330896]: Rejected connect attempt from
Oct 28 13:54:59 NOTICE[-167330896]: Rejected connect attempt from</pre>

Checking logger.c, it casts all return values from pthread_self() to longs before printing them:

<pre>snprintf(buf, sizeof(buf), "VERBOSE[%ld]: ", (long)pthread_self());</pre>

pthread_self() returns an pthread_t, which is (according to bits/pthread_types.h) an unsigned long int.

So it should be:

<pre>snprintf(buf, sizeof(buf), "VERBOSE[%lu]: ", (long)pthread_self());</pre>

But since the numbers given then are pretty big:
<pre>Oct 28 14:08:17 WARNING[4144590976]: Unable to get our IP address, Skinny disabled
Oct 28 14:08:17 WARNING[4144590976]: Ignoring switchtype</pre>

Converting it to hex would be a better thing (%08lx), but a better thing would be to replace pthread_self() with getpid(), if Linux has a seperate process ID for every thread (which I don't know if it does).


Please note that pthread_self under FreeBSD is an structure instead of a single integer (which would make it an even better reason to use getpid() instead of pthread_self(). Or to use %p instead of %ld/%lu. So many options :-)
Comments:By: Mark Spencer (markster) 2004-11-01 11:24:09.000-0600

Fixed in CVS, just used getpid for non-linux and gettid for linux.

By: Russell Bryant (russell) 2004-11-02 21:01:35.000-0600

fixed in 1.0 - will be in 1.0.3

By: Digium Subversion (svnbot) 2008-01-15 15:12:29.000-0600

Repository: asterisk
Revision: 4153

U   branches/v1-0/logger.c

r4153 | russell | 2008-01-15 15:12:29 -0600 (Tue, 15 Jan 2008) | 2 lines

Use getpid (non-linux) or gettid(linux) for thread identification (bug ASTERISK-2698)