Bug 453284

Summary: Mysterious crash in __regexec
Product: [Fedora] Fedora Reporter: Matěj Cepl <mcepl>
Component: glibcAssignee: Jakub Jelinek <jakub>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 9CC: drepper, jan.kratochvil, mcepl, peter
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-10-07 19:16:55 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
full bug-buddy report, so that we don't have to rely on the external bugzilla for backtrace
none
output of running valgrind --leak-check=full --show-reachable=yes --log-file=empathy-valgrind-log.txt /usr/bin/empathy
none
valgrind --leak-check=full --show-reachable=yes --db-attach=yes --log-file=empathy-valgrind-log.txt /usr/bin/empathy
none
output of valgrind
none
with empathy upgraded to the last version empathy-0.23.4 (private build)
none
one more crash report, this time with the special account created just for testing none

Description Matěj Cepl 2008-06-28 21:47:05 UTC 
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:
Comment 1 Matěj Cepl 2008-06-28 21:49:27 UTC 
Created attachment 310519 [details]
full bug-buddy report, so that we don't have to rely on the external bugzilla for backtrace
Comment 2 Peter Gordon 2008-06-28 22:52:36 UTC 
Does this only happen with a specific connection manager/protocol? How odd. :/
Comment 3 Matěj Cepl 2008-06-29 06:48:48 UTC 
(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.
Comment 4 Matěj Cepl 2008-06-30 06:38:44 UTC 
(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
Comment 5 Jakub Jelinek 2008-07-02 08:25:39 UTC 
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)?
Comment 6 Matěj Cepl 2008-07-02 15:42:39 UTC 
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).
Comment 7 Matěj Cepl 2008-07-02 16:37:59 UTC 
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.
Comment 8 Matěj Cepl 2008-07-29 16:22:26 UTC 
Created attachment 312901 [details]
output of valgrind

valgrind was fixed now
Comment 9 Matěj Cepl 2008-07-29 16:39:34 UTC 
Created attachment 312903 [details]
with empathy upgraded to the last version empathy-0.23.4 (private build)
Comment 10 Matěj Cepl 2008-07-29 16:53:52 UTC 
Created attachment 312904 [details]
one more crash report, this time with the special account created just for testing
Comment 11 Ulrich Drepper 2008-08-03 18:52:26 UTC 
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.
Comment 12 Matěj Cepl 2008-10-07 19:16:55 UTC 
I have left empathy and telepathy so cannot reproduce anymore. Closing as INSUFFICIENT_DATA (that's called anticipatory breach in legalese ;-)).