Possible bug; latest kernels with LinuxThreads

Possible bug; latest kernels with LinuxThreads

[David Sanchez]

Hi,

I don't know if this could be a kernel bug or it's only caused by my bad 
programming and poor knowledge  :-), but the fact is I can't get a threaded 
daemon I'm developing run on latest kernels.

It has been tested on 2.4.9 and lower releases successfully, but it doesn't 
work on 2.4.13, 2.4.14 and 2.4.15-pre4. Linux distribution is RedHat 6.2 
and I've tested on several machines, including SMP and non-SMP.

The daemon listen to a port and creates a new thread when a new client 
connects to it. It also has a thread which is listening to a SIGALRM signal 
to implement a timer. When SIGALRM is raised the function handler creates a 
new thread, and here's when the daemon crashes with segmentation fault 
using latest kernels.

Linking with ElectricFence I'm able to coredump the daemon in this moment, 
and with gdb this is what a get:

# gdb chsld --core core.7655
GNU gdb 19991004
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
Core was generated by `chsld'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/local/lib/libiodbc.so.2...done.
Reading symbols from /usr/local/lib/mysql/libmysqlclient.so.9...done.
Reading symbols from /lib/libpthread.so.0...done.
Reading symbols from /usr/lib/libstdc++-libc6.1-1.so.2...done.
Reading symbols from /lib/libm.so.6...done.
Reading symbols from /lib/libc.so.6...done.
Reading symbols from /lib/libdl.so.2...done.
Reading symbols from /lib/libnsl.so.1...done.
Reading symbols from /usr/lib/libz.so.1...done.
Reading symbols from /lib/libcrypt.so.1...done.
Reading symbols from /lib/ld-linux.so.2...done.
Reading symbols from /lib/libnss_files.so.2...done.
#0 0x40053f0f in __pthread_create_2_1 (thread=0x40244fc4, attr=0x40244fc8,
start_routine=0x804ae20 <gMantThread(void *)>, arg=0x40244fc4) at pthread.c:488
488 pthread.c: No such file or directory.
(gdb) bt
#0 0x40053f0f in __pthread_create_2_1 (thread=0x40244fc4, attr=0x40244fc8,
start_routine=0x804ae20 <gMantThread(void *)>, arg=0x40244fc4) at pthread.c:488
#1 0x80730f3 in MCThread::Create () at chsld.cc:130
#2 0x804f13d in MCVXLocaldApp::TimerEvent (this=0x8090260, p=0x80796b4) at 
chsld.cc:162
#3 0x80570d0 in MCSimpleApp::OnTimer () at chsld.cc:130
#4 0x8056e31 in AppTimer (n=14) at chsld.cc:75
#5 0x40054552 in pthread_sighandler (signo=14, ctx={gs = 0, __gsh = 0, fs = 
0, __fsh = 0, es = 43,
__esh = 0, ds = 43, __dsh = 0, edi = 3212835916, esi = 3212835640, ebp = 
3212836044, esp = 3212835588,
ebx = 3212835640, edx = 1075507692, ecx = 3212835640, eax = 4294967292, 
trapno = 0, err = 0,
eip = 1075121249, cs = 35, __csh = 0, eflags = 582, esp_at_signal = 
3212835588, ss = 43, __ssh = 0,
fpstate = 0xbf7ff888, oldmask = 2147483648, cr2 = 0}) at signals.c:96
#6 0x400ddc68 in __restore () at 
../sysdeps/unix/sysv/linux/i386/sigaction.c:127
#7 0x805683b in MCVXLocaldApp::StartTimer (this=0x8090260) at chsld.cc:812
#8 0x8056cf0 in gTimerThread () at chsld.cc:106
#9 0x40051b85 in pthread_start_thread (arg=0xbf7ffe40) at manager.c:241
(gdb)


Any ideas? any help would be appreciated :-) thanks in advance.


David Sánchez
Veloxia Network,S.L.

dsanchez@veloxia.com

Re: Possible bug; latest kernels with LinuxThreads

[Davide Libenzi]

On Sun, 18 Nov 2001, David Sanchez wrote:

> #0 0x40053f0f in __pthread_create_2_1 (thread=0x40244fc4, attr=0x40244fc8,
> start_routine=0x804ae20 <gMantThread(void *)>, arg=0x40244fc4) at pthread.c:488

In that case a look at the code always helps :


int __pthread_create_2_1(pthread_t *thread, const pthread_attr_t *attr,
             void * (*start_routine)(void *), void *arg)
{
  pthread_descr self = thread_self();
  struct pthread_request request;
  if (__pthread_manager_request < 0) {
    if (__pthread_initialize_manager() < 0) return EAGAIN;
  }
  request.req_thread = self;
  request.req_kind = REQ_CREATE;
  request.req_args.create.attr = attr;
  request.req_args.create.fn = start_routine;
  request.req_args.create.arg = arg;
  sigprocmask(SIG_SETMASK, (const sigset_t *) NULL,
              &request.req_args.create.mask);
  __libc_write(__pthread_manager_request, (char *) &request,
	sizeof(request));
  suspend(self);
  if (THREAD_GETMEM(self, p_retcode) == 0)

>>>>    *thread = (pthread_t) THREAD_GETMEM(self, p_retval);

  return THREAD_GETMEM(self, p_retcode);
}

The line marked >>>> is line 488 in pthread.c , are you plain sure that
you're not passing a NULL thread id ptr ?





- Davide

Re: Possible bug; latest kernels with LinuxThreads

[David Sanchez]

>The line marked >>>> is line 488 in pthread.c , are you plain sure that
>you're not passing a NULL thread id ptr ?

Totally sure :-)

#0 0x40053f0f in __pthread_create_2_1 (thread=0x40244fc4, attr=0x40244fc8,

thread = 0x40244fc4 and attr=0x40244fc8, both parameters are inside a class 
of type MCThread, which begins with:

class MCThread {

protected:
         pthread_t m_thread;
         pthread_attr_t m_thread_attr;

Class is correctly allocated with "new", and also remember that the daemon 
runs without any problem and in a production environment with kernel 2.4.9 
and lowers.

Thank you very much,

David Sánchez
Veloxia Network,S.L.

dsanchez@veloxia.com

Re: Possible bug; latest kernels with LinuxThreads

[Davide Libenzi]

On Sun, 18 Nov 2001, David Sanchez wrote:

> Class is correctly allocated with "new", and also remember that the daemon
> runs without any problem and in a production environment with kernel 2.4.9
> and lowers.

Try a "p self" from frame #0




- Davide

Re: Possible bug; latest kernels with LinuxThreads

[David Sanchez]

At 19:11 17/11/2001 -0800, you wrote:
>On Sun, 18 Nov 2001, David Sanchez wrote:
>
> > Class is correctly allocated with "new", and also remember that the daemon
> > runs without any problem and in a production environment with kernel 2.4.9
> > and lowers.
>
>Try a "p self" from frame #0

Seems OK...

[...]
#7  0x805683b in MCVXLocaldApp::StartTimer (this=0x8090260) at chsld.cc:812
#8  0x8056cf0 in gTimerThread () at chsld.cc:106
#9  0x40051b85 in pthread_start_thread (arg=0xbf7ffe40) at manager.c:241

[...]

(gdb) p self
$1 = 0xbf7ffe40

Thanks again,

David Sánchez
Veloxia Network,S.L.

dsanchez@veloxia.com

Re: Possible bug; latest kernels with LinuxThreads

[Davide Libenzi]

On Sun, 18 Nov 2001, David Sanchez wrote:

> At 19:11 17/11/2001 -0800, you wrote:
> >On Sun, 18 Nov 2001, David Sanchez wrote:
> >
> > > Class is correctly allocated with "new", and also remember that the daemon
> > > runs without any problem and in a production environment with kernel 2.4.9
> > > and lowers.
> >
> >Try a "p self" from frame #0
>
> Seems OK...
>
> [...]
> #7  0x805683b in MCVXLocaldApp::StartTimer (this=0x8090260) at chsld.cc:812
> #8  0x8056cf0 in gTimerThread () at chsld.cc:106
> #9  0x40051b85 in pthread_start_thread (arg=0xbf7ffe40) at manager.c:241

Try a disassemble from frame #0 to get the exact machine instruction where
it crashes.



- Davide