Re: [bdbxml] Crash in dbxml_javaJNI.XmlResults_next__SWIG_0

I'll create a separate support request, and take this off the list.
We'll report back to the list when it's resolved.

Regards,

George

On Sep 13, 2005, at 8:05 AM, Klaas Freitag wrote:

> On Monday 12 September 2005 18:19, George Feinberg wrote:
>
> Hi George,
>
> thanks for your help, we appreciate that very much.
>
>>
>> I cannot, in fact reproduce the error with the rewritten code.
>>
> We can reproduce the bug on several machines here. However it
> happens not always, but quite often (on hyperthreading cpus, see
> below).
>
>
>> The behavior you are seeing is what I was able to reproduce
>> with the old code.  I don't think it's a build issue.
>>
>> Because the crash occurs when deleted memory is referenced,
>> a memory-checking tool, such as valgrind can help debug
>> the problem.  Can you try running under valgrind to see
>> if it can be further isolated?
>>
> I tried it with valgrind, but did not have real success. I think
> that is because we run the the test program through java where
> we do not have sources nor debug versions.
>
> All valgrind spits out is the following:
>
> valgrind --tool=memcheck java -Djava.library.path=$DBXML/  
> MultithreadingTestCase
> ==26541== Memcheck, a memory error detector for x86-linux.
> ==26541== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward  
> et al.
> ==26541== Using valgrind-2.2.0, a program supervision framework for  
> x86-linux.
> ==26541== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward  
> et al.
> ==26541== For more details, rerun with: -v
> ==26541==
> ==26541== Conditional jump or move depends on uninitialised value(s)
> ==26541==    at 0x1B8EEE03: (within /lib/ld-2.3.4.so)
> ==26541==    by 0x1B8E6F7A: (within /lib/ld-2.3.4.so)
> ==26541==    by 0x1B8F4BC0: (within /lib/ld-2.3.4.so)
> ==26541==    by 0x1B8E53DA: (within /lib/ld-2.3.4.so)
> ==26541==
> ==26541==    [ some more of these ]
>
> Creating container... done
> Waiting for threads...
> thread #1 done
> thread #2 done
> thread #3 done
> thread #4 done
>
> ****************
> Another exception has been detected while we were handling last error.
> Dumping information about last error:
> ERROR REPORT FILE = (N/A)
> PC                = 0x08197dba
> SIGNAL            = 11
> FUNCTION NAME     = (N/A)
> OFFSET            = 0xFFFFFFFF
> LIBRARY NAME      = (N/A)
> Please check ERROR REPORT FILE for further information, if there is  
> any.
> Good bye.
>
> === snip ====
>
> Is there any chance to enable more debug information from dbxml
> or to let the java interpreter to give more helpfull information?
> Any hints how to call valgrind more informative?
>
> Another suspicion is that it has something to do with the kernel
> we are running: It seems as if the problem happens way oftener on
> SMP kernels than on single processor kernels, however we were also
> able to reproduce it on single processor kernel.
>
> Thanks for any help,
>
> Klaas
>
> -- 
>                                                Klaas Freitag
>                           Novell - SUSE R&D - Internal Tools
>
>
> ------------------------------------------
> To remove yourself from this list, send an
> email to [email protected]
>
>



------------------------------------------
To remove yourself from this list, send an
email to [email protected]