Re: [xml] 2.4.27 thread problems

Hi there,

I didn't make any progress on Windows, so I'm debugging on Linux now.

My last modification to threads.c involves exactly two changes to pthreads code, both the work of the indenter. No change to the instructions, just a space more or less at the beginning of the line.

One change I made to testThreads.c is Windows specific (Windows/MSVC does not have unistd.h) and has nothing to do with Unix or pthreads.

I have recompiled libxml2 with the previous version of threads.c and the error remains.

Windows implementation of pthreads causes and handles the exception again and again, which results in an infinite loop. No obvious logic on if, when and where in libxml code it happens, appearantly random.

On Linux, testThreads booms with a segmentation fault sometimes, sometimes it passes. Sometimes it crashes after it creates just a few threads, other times it runs for a while until it crashes. It always crashes at about the same place and the following crash location is interesting:

  Program received signal SIGILL, Illegal instruction.
  [Switching to Thread 29726 (LWP 22306)]
  0x400a3e2b in xmlXPathCompStep (ctxt=0x804e198) at xpath.c:8557
  8557            ctxt->comp->last = -1;
  (gdb) bt
  Reading in symbols for parser.c... and parserInternals.c...done.
  #0  0x400a3e2b in xmlXPathCompStep (...) at xpath.c:8557
  #1  0x40056b68 in xmlParseDocument (...) at parser.c:7754
  #2  0x4005b8d8 in xmlSAXParseFileWithData (...) at parser.c:10296

Hmmm...???? Illegal instruction? The dissasembly of the specified address (0x400a3e2b) reveals that there is no instruction at that address:

  0x400a3e21 <xmlXPathCompStep+1269>:     mov    0x8(%ebp),%eax
  0x400a3e24 <xmlXPathCompStep+1272>:     mov    0x20(%eax),%edx
  0x400a3e27 <xmlXPathCompStep+1275>:     movl   $0xffffffff,0xc(%edx)
  0x400a3e2e <xmlXPathCompStep+1282>:     mov    %esi,%esi
  0x400a3e30 <xmlXPathCompStep+1284>:     mov    0x8(%ebp),%eax
  0x400a3e33 <xmlXPathCompStep+1287>:     mov    (%eax),%edx

Somehow the instruction pointer has been filled with an address which points to the limbo between movl and mov.

When I look at the code in parser.c:7754 (stack frame #1), I don't see an execution path which leads to the xmlXPathCompStep function.

I assume the following: The xmlOnceInit function calls pthread_key_create and gives it the pointer to the xmlFreeGlobalState function. Pthreads saves this somewhere and calls xmlFreeGlobalState when it is about to destroy the thread-specific data (when the thread exits). It seems that something overwrites the pointer to xmlFreeGlobalState function with an invalid address and when pthreads tries to call it, it crashes.

In any case, this is a hard one. It has nothing to do with the recent changes to threads.c. Anyone has an idea?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]