From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030527 Debian/1.3.1-2 Description of problem: Note: I am here only mimicking with mandrake but the bug exists in redhat 9 .It has been verified many a times and i found that bug exists in Redhat 9.So there must be a common solution. Hi, I recently installed viavoice tts .I thought that the bug below was caused due to errors in viavoice but later when i did some searching i found that it is due to glibc 2.3 which segfaults during the execution.I arrived at this conclusion of glibc because i tried debian glibc 2.3 which works fine and the redhat glibc 2.3 (from 9.0 installation) is causing the problem. So to make sure that bug is due to redhat glibc 2.3 i installed the viavoice in redhat 7.3.It worked well.Later upon searching the net i couldn't find much info about how to correct the problem until i read a post saying that it was a bug due to glibc redhat patch.So what should i do ? Update glibc or can it be worked around without updating glibc . http://mailman.pvl.at/pipermail/pvx-tech/2003-April/000053.html The "###DEBUG Hi1" was added by me for finding out which function is causing to segfault.Unfortunately it is the eciNew() function. Also please tell me what other info should i attach along with bugs.What are the relevant things which will help you to solve the problem more easily. More info at this url .I posted it once but it was giving me URI too long error.So here is the link. http://sources.redhat.com/ml/bug-glibc/2003-07/msg00044.html Version-Release number of selected component (if applicable): glibc-2.3.2-11.9, kernel-2.4.20-8 How reproducible: Always Steps to Reproduce: 1.Install viavoice tts rpm 2.run ./cmdlinespeak 3. See the segfault rpm -ivh viavoice /usr/lib/viavoicetts ./cmdlinespeak Actual Results: It crashed and core was produced Expected Results: ./cmdlinespeak should run. Instead it segfaults dumps core Additional info: Please see the description
Well, first of all, we issued glibc errata for RHL9, so you should be testing with glibc-2.3.2-27.9, not -11.9. From the backtrace it looks like the application uses the braindamaged <regexp.h> API. To debug this, I need to know: a) what arguments has the compile() supposedly in /usr/lib/enu50.so been called with (if more times, then the one which uses the same expbuf as the segfaulting advance is interesting) b) what arguments have been passed to regcomp from the compiled function c) what arguments have been passed to advance when it segfaulted a) compile takes 1 string, 1 expbuf ptr, 1 endbuf ptr and 1 intereger, so if you insert breakpoint on the first insn in it you can just x/5w $esp and x/1s *(char **)($esp + 4) in gdb b) regcomp takes 1 expbuf ptr, 1 string with regular expression, 1 integer again, x/4w $esp, x/1s *(char **)($esp + 8) in gdb c) advance takes 1 string and 1 expbuf ptr, so x/3w $esp, x/1s *(char **)$(esp + 4)
Ping. Did you try the current errata glibc? And more importantly, did you look at IBM for updates ti this program? Given the highly suspicious interfaces they are using I put my money on an application bug.
No response in a month. I can see no bug in glibc. Closing now.