Hi Cyril, On Sat, Apr 16, 2016 at 12:39:41AM +0200, Cyril Chaboisseau wrote: > Hi Carsten, > > Le 14 avril vers 16:28, Carsten Schoenert écrivait: > > > anyway, here is the bt: > > > [SNIP] > > > > your posted gdb log doesn't contain a useful backtrace, it's only a log > > of the thread 1. > > OK, fine > sorry for not getting the proper feedback > > what would have been the right way to give a comprehensive backtrace?
If you have no deeper experience with gdb than you should follow the steps that are described in the wiki. This will produce a complete full log of all used threads. That's most enough for us to get a idea where to look. To let gdb post the relevant parts of the source code you have to tell gdb where to find it. If you have checked out the git repository from git.debian.org https://anonscm.debian.org/cgit/pkg-mozilla/icedove.git than you can do this easily. You need to check out the right Debian version (e.g. debian/38.7.0-1) and put the debian patches on top. With git-buildpackage (this is the tool we use for the package workflow) it would be like this: cd $(ICEDOVE_GIT_TREE) # or clone the repo first git checkouto debian/38.7.0-1 # create a local git branch as suggested by git git checkout -b my_38.7.0 # put the patches on top gbp pq import Now set a substitution path inside the gdb session as the source isn't local placed like while building on the buildd. # inside gdb (gdb) set substitute-path /build/icedove-nkxBa2/icedove-38.7.0 /your/local/path/to/icedove Now just run the Icedove application again and gdb will show you hopefully the related source code parts. You can use all the gdb commands to debug the problem like breakpoints, stepping etc. There are various howto's out there how to use gdb. > is "thread apply all bt" would have been fine? Mostly. This will give a output of all backtraces of the threads that was running. You will get plenty of backtraces as Icedove is a multi threaded application. Afterwards there is strong need to figure out which parts of the lock are relevant. > well, that is great you could pinpoint the relevant buggy part That's already visible in the gdb log. The getter function is a pointer and points nowhere, that's the problem. > Program received signal SIGSEGV, Segmentation fault. > nsProtocolProxyService::ApplyFilters (this=this@entry=0x7fffd77ecf20, > channel=channel@entry=0x7fffbf705780, info=..., > list=list@entry=0x7fffffff6990) at > /build/icedove-nkxIAZ/icedove-38.6.0/mozilla/netwerk/base/nsProtocolProxyService.cpp:1885 > warning: Source file is more recent than executable. > 1885 getter_AddRefs(result)); > (gdb) p getter_AddRefs > No symbol "getter_AddRefs" in current context. By this the application is crashing. Somethere in the deep there is no check for the existence of the pointer. The question is why and there to look. [SNIP] > could this be the bug you're looking for: > https://bugzilla.mozilla.org/show_bug.cgi?id=1220564 Maybe, from a fist look I'd say can be or not. ;) To test this you would need to build a new Icedove with this change and simple check. The pointed bug is marked as fixed in FF46, the code for Thunderbird is the same so it should be simply to adopt a patch and build all together. But I won't hav ethe time for this. So if you can test this would be fine. Regards Carsten
