Description of problem: Not much to be told -- when trying new upstream tarball of empathy (http://live.gnome.org/Empathy; multi-protocol IM/IRC client based on the Telepathy framework), then when it should open actual window with chat (greeting from Nickserv @ Freenode is usually the case), whole program crashes with the backtrace as visible at http://bugzilla.gnome.org/show_bug.cgi?id=540688 Filing a bug here, because upstream author of the program doesn't see any reason why his program should fail there and in desperation he is blaming glibc. Does this bug makes any sense to you? Version-Release number of selected component (if applicable): glibc-2.8-3.i686 gcc-4.3.0-8.i386 glib2-2.16.3-7.fc9.i386 How reproducible: 100% (both on Fedora 9 as well as on Rawhide, where actually current empathy is absolutely not working for me) Steps to Reproduce: 1.build empathy 0.23.3 on Fedora 9 or install the same version from the Rawhide repositories 2.run the program 3.wait until the empathy icon in the status area blinks, indicating that new message has arrived 4.double click the icon Actual results: crash Expected results: a window with the conversation opens Additional info:
Created attachment 310519 [details] full bug-buddy report, so that we don't have to rely on the external bugzilla for backtrace
Does this only happen with a specific connection manager/protocol? How odd. :/
(In reply to comment #2) > Does this only happen with a specific connection manager/protocol? How odd. :/ Well, I never got further than to IRC (because Freenode's Nickserv calls myself automagically) -- will test with switched off IRC.
(In reply to comment #3) > (In reply to comment #2) > > Does this only happen with a specific connection manager/protocol? How odd. :/ > > Well, I never got further than to IRC (because Freenode's Nickserv calls myself > automagically) -- will test with switched off IRC. Reproduced with just Jabber on -- no IRC account was started -- http://bugzilla.gnome.org/show_bug.cgi?id=540862
Can you run it under valgrind or some other memory allocation debugger? Can you distill just the regcomp/regexec calls on that particular regex_t object (with arguments they are called) and still reproduce the segfault (setlocale might be needed too for the corresponding locale)?
Created attachment 310811 [details] output of running valgrind --leak-check=full --show-reachable=yes --log-file=empathy-valgrind-log.txt /usr/bin/empathy (In reply to comment #5) > Can you run it under valgrind or some other memory allocation debugger? Hmm, this was much less geeky than I was afraid, and it looks kind of promising. > Can you distill just the regcomp/regexec calls on that particular regex_t > object (with arguments they are called) and still reproduce the segfault > (setlocale might be needed too for the corresponding locale)? That's probably too much C programming for me. I will let know upstream about it (as well as about the results of valgrinding).
Created attachment 310823 [details] valgrind --leak-check=full --show-reachable=yes --db-attach=yes --log-file=empathy-valgrind-log.txt /usr/bin/empathy Trying to get backtrace, I got something, but unfortunately bug 453688 stopped from going further.
Created attachment 312901 [details] output of valgrind valgrind was fixed now
Created attachment 312903 [details] with empathy upgraded to the last version empathy-0.23.4 (private build)
Created attachment 312904 [details] one more crash report, this time with the special account created just for testing
If there is a problem with regex then it is simple to make sure it's the reason. The regex results only depend on the compiled expression and then the text passed to regexex (plus the implied constant data from the locale). So, to go forward, log all this information and then put it in a test program. If this doesn't fail then there are problems in the program.
I have left empathy and telepathy so cannot reproduce anymore. Closing as INSUFFICIENT_DATA (that's called anticipatory breach in legalese ;-)).