Hi! > Thanks for reporting. At the first glance, these are my (probably > wrong) thoughts: > > As expected, it works well here (amd64, python2.6, rdflib 2.4.2-1+b1).
Yes, otherwise the enigmail build would fail on more architectures. > Your debug steps are clear, but I'm not really sure if python-rdflib > is the one to blame here. "Bus error" looks more like an internal > Python interpreter malfunction than a problem in the library itself, > maybe caused by porting issues. That's possible but less likely because there is (and was, AFAIK) no bug report against the python package involving specifically the mips architecture. As a bug in the interpreter would very likely also affect other builds, I think it is safe to say the interpreter is OK. > OTOH, given it fails calling query() (SPARQL query parsing is > involved), the problem may be in the C extension (SPARQLParserc.so). > As a starting point, I should investigate if SIGBUS is raised either > by a problem in the extension or is Python-related. > > If you don't mind, I've a couple of questions for you. > > Perhaps this is a dumb question but, is Qemu MIPS emulation reliable > enough to use it for debugging purposes? Have you tried it in real > hardware? Does it fail anyway? I don't have shell access to real hardware, but the bus error was first seen in the build log of enigmail, and the builds are done on real hardware. So qemu just behaves as some real hardware. And a qemu armel image also helped me to debug a another build issue. So I think the results can really be trusted. > Do you know about any other python library with C extensions > experiencing the same behavior in your Qemu image? Or maybe crashing > with other Python/OS/whatever internal errors? No, I only came over it because the failing enigmail build. However, I've asked on the debian-mips mailing list to do test a build of enigmail (that was before I set up the qemu image). In the mean time, someone answered and told me that it also failed on his box, but with "Segmentation fault". As he uses kernel 2.6.34, it's possible that it's just the signal that changed (SIGBUS and SIGSEGV are both related to memory access) And yes, I would suspect the C extension to be the culprit, but we need a way to prove this. I'm currently tring to rebuild rdflib in the emulator. My test case succeeds when I compile with DEB_BUILD_OPTIONS="noopt nostrip", so I'm now trying with DEB_BUILD_OPTIONS unset. Maybe the bug is caused by a bug in an old gcc version and gcc is now fixed. WM -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
