Created attachment 446493 [details] reproducer Description of problem: After update to glibc-2.12.90-8.x86_64 one of OO.o's internal build tools started to fail. I tracked it down to strncasecmp call (masked as strnicmp by #define in the source code :). It fails consistently at the same place, but only there: it runs fine most of the time :( See steps to reproduce for how to build the failing binary from sources; if you don't want to/need to do this, you can use the attached one. Version-Release number of selected component (if applicable): glibc-2.12.90-8.x86_64 How reproducible: always Steps to Reproduce: 1. get the attached tarball and unpack it somewhere 2. go to the unpacked dir 3. ./prepare.sh; this will do some compiling and fails at the end 4. ./solver/300/unxlngx6/bin/xml2cmp -types stdout stoc/unxlngx6/misc/jen.xml or 1. get the attached binary and XML source 2. ./xml2cmp -types stdout $(pwd)/jen.xml Actual results: strncasecmp fails, causing build error: "Syntax error missing or not matching end tag in file: ../../unxlngx6/misc/jen.xml in line 60" Expected results: build runs smoothly (or, as smoothly as it is possible with OO.o...) Additional info: It works if there are less than three components in the path to the XML source (i.e. xml2cmp a/b/jen.xml is fine, xml2mp a/b/c/jen.xml is not). It works with glibc-2.12.90-6.x86_64 . Maybe related to bug 632555 ?
Created attachment 446494 [details] precompiled binary
Created attachment 446495 [details] XML source
Created attachment 446496 [details] snippet from gdb session
update: works with glibc-2.12.90-7.x86_64
Created attachment 446670 [details] Attempt to reproduce I cannot reproduce any problem. When I use your test program (compiled from source or the binary) I get com.sun.star.lang.DisposedException com.sun.star.lang.IllegalArgumentException com.sun.star.java.InvalidJavaSettingsException com.sun.star.java.JavaDisabledException com.sun.star.java.JavaInitializationException com.sun.star.java.JavaNotFoundException com.sun.star.java.JavaVMCreationFailureException com.sun.star.beans.NamedValue com.sun.star.beans.PropertyValue com.sun.star.java.RestartRequiredException com.sun.star.uno.TypeClass com.sun.star.uri/ExternalUriReferenceTranslator com.sun.star.lang.WrappedTargetRuntimeException com.sun.star.uno.XAggregation com.sun.star.lang.XComponent com.sun.star.uno.XComponentContext com.sun.star.container.XContainer com.sun.star.container.XContainerListener com.sun.star.uno.XCurrentContext com.sun.star.lang.XInitialization com.sun.star.task.XInteractionAbort com.sun.star.task.XInteractionContinuation com.sun.star.task.XInteractionHandler com.sun.star.task.XInteractionRequest com.sun.star.task.XInteractionRetry com.sun.star.java.XJavaThreadRegister_11 com.sun.star.java.XJavaVM com.sun.star.util.XMacroExpander com.sun.star.lang.XMultiServiceFactory com.sun.star.container.XNameAccess com.sun.star.lang.XServiceInfo com.sun.star.registry.XSimpleRegistry com.sun.star.lang.XSingleComponentFactory com.sun.star.lang.XSingleServiceFactory com.sun.star.lang.XTypeProvider com.sun.star.uno.XWeak This is not what you wrote would happen and likely a different problem. When I try to recreate the problematic call I also don't see any problem (see the attachment). It works for all kinds of locales. Note, this is with the upstream glibc, not the Fedora binary. But these two shouldn't differ. If you still can reproduce the issue look at the attachment. Tweak it, if necessary, to reduce the test case. I tried all three x86-64 strncasecmp implementations and nothing fails.
(In reply to comment #5) > Created attachment 446670 [details] > Attempt to reproduce > > I cannot reproduce any problem. When I use your test program (compiled from > source or the binary) I get > > com.sun.star.lang.DisposedException com.sun.star.lang.IllegalArgumentException > --- cut --- > > This is not what you wrote would happen and likely a different problem. > No, that's the intended output. > > When I try to recreate the problematic call I also don't see any problem (see > the attachment). It works for all kinds of locales. > > Note, this is with the upstream glibc, not the Fedora binary. But these two > shouldn't differ. > > If you still can reproduce the issue look at the attachment. Tweak it, if > necessary, to reduce the test case. I tried all three x86-64 strncasecmp > implementations and nothing fails. I wish I couldn't reproduce it :( The test program gives me s = 0x600db0, t = 0x601dbb, i = 62, j = 0 , which is obviously wrong. I tried it without selinux, with older kernel (kernel-2.6.36-0.9.rc2.git3.fc15) and gcc (gcc-4.5.1-1.fc14)--both from 20100826 rawhide snapshot, because I know for sure I had no build problem at that time--but so far the only thing I found is it works with glibc up to glibc-2.12.90-7.x86_64 and doesn't work with any newer. My current versions of (possibly) related packages are: glibc-2.12.90-10.x86_64 gcc-4.5.1-3.fc14.x86_64 kernel-2.6.36-0.20.rc3.git4.fc15.x86_64
Created attachment 447176 [details] preprocessed source of the test case I'm attaching preprocessed source and assembler code of the test case, just in case there is something wrong with my environment.
Created attachment 447178 [details] assembler code of the test case
What processor do you have? The version selected depends on this. What's the output of /proc/cpuinfo? Is it virtualized?
Created attachment 447428 [details] /proc/cpuinfo No, it's not virtualized.
The notorious Pentium D? I think that processor was ripe with bugs. I have no way to reproduce this myself so you'll have to do it. You probably will have to single step through the code. Start my test program with gdb, place a breakpoint on __strncasecmp_l_sse2. If this doesn't work step through the function all until you arrive at the beginning of the real code. Then step through the code instruction by instruction using 'si' and after every instruction print the register which has been modified. I any register is modified. Best to use the hex format. At the beginning show all registers once: info all-registers The code starts with mov (%rcx),%rax testl $0x0,0x278(%rax) jne somehwere... test %rdx,%rdx je somewhere... cmp $0x1,%rdx je somewhere You can skip all the above as long as you arrive at the following instruction. Here I now intermix the print info you should provide. I hope you get the idea. mov %rdx,%r11 p/x $r11 mov %esi,%ecx p/x $rcx mov %edi,%eax p/x $rax and $0x3f,%rcx and $0x3f,%rax movdqa 0x0(%rip),%xmm5 p/x $xmm5.v16_int8 movdqa 0x0(%rip),%xmm6 p/x $xmm6.v16_int8 ... Note the format used for printing the SSE registers. If you don't know x86 assembler well enough to determine which registers are modified (if any, the test instructions above don't modify anything) then just type info all-registers after every instruction executed using 'si'. You might want to start gdb under script. On a terminal command line, just type script, then start and run the debugger, terminate the debugger, and then press Control-D. You'll end up with a file named 'typescript' in the current dir which has all the text output in it. That's the info I need.
Also, are you sure you have the latest microcode update for the Pentium D? As I wrote before, the processor was buggy.
If you think it is a strncasecmp problem, please find a small, standalone testcase. I will look into it.
(In reply to comment #13) > If you think it is a strncasecmp problem, please > find a small, standalone testcase. I will look > into it. HJ, my attachment from comment #5 is a small test case.
(In reply to comment #14) > (In reply to comment #13) > > If you think it is a strncasecmp problem, please > > find a small, standalone testcase. I will look > > into it. > > HJ, my attachment from comment #5 is a small test case. On cpu family : 15 model : 6 model name : Intel(R) Pentium(R) D CPU 3.73GHz stepping : 4 with glibc-2.12.1-2.f13.x86_64, I got [hjl@gnu-33 bz632560]$ ./a.out s = 0x600db0, t = 0x601dbb, i = 0, j = 0 [hjl@gnu-33 bz632560]$ The output is the same as on Core i7.
(In reply to comment #15) > [hjl@gnu-33 bz632560]$ ./a.out > s = 0x600db0, t = 0x601dbb, i = 0, j = 0 > [hjl@gnu-33 bz632560]$ > > The output is the same as on Core i7. That's what I see, too. But you have to make sure you're also testing it on a machine which will use the sse2 version, not the ssse3 nor sse4.2 version. As you see in comment #6, this isn't the case on that Pentium D. Whenever I see that processor mentioned I think about processor bugs. That's why I cc:ed you. My guess is that a BIOS update is needed since I cannot reproduce it.
(In reply to comment #16) > (In reply to comment #15) > > [hjl@gnu-33 bz632560]$ ./a.out > > s = 0x600db0, t = 0x601dbb, i = 0, j = 0 > > [hjl@gnu-33 bz632560]$ > > > > The output is the same as on Core i7. > That's what I see, too. But you have to make sure you're also testing it on a > machine which will use the sse2 version, not the ssse3 nor sse4.2 version. I tested it on model name : Intel(R) Pentium(R) D CPU 3.73GHz It doesn't have SSSE3. > As you see in comment #6, this isn't the case on that Pentium D. Whenever I > see that processor mentioned I think about processor bugs. That's why I cc:ed > you. > My guess is that a BIOS update is needed since I cannot reproduce it. It is a good idea.
Created attachment 448524 [details] gdb session log
(In reply to comment #18) > Created attachment 448524 [details] > gdb session log (In reply to comment #18) > Created attachment 448524 [details] > gdb session log Please answer the following questions: 1. Which testcase? 2. Does it fail every time on the same machine? 3. Does it fail on different machines without SSSE3?
> 1. Which testcase? u.c from comment 5 > 2. Does it fail every time on the same machine? Yes. I thought I was pretty explicit about it in my previous comments... > 3. Does it fail on different machines without SSSE3? I suppose you do mean SSE2. It doesn't fail on my laptop with Intel Core i3, where SSE3 version is used, AFAICS.
(In reply to comment #20) > > 3. Does it fail on different machines without SSSE3? > I suppose you do mean SSE2. It doesn't fail on my laptop with Intel Core i3, I meant "without SSSE3". On machines without SSSE3, SSE2 version will be used. Please try it on other machines without SSSE3.
Please upload /tmp/cache.info.tar.gz created by: # cd / # tar cfz /tmp/cache.info.tar.gz ./sys/devices/system/cpu/cpu0/cache
I found and fixed one more limit check in strncasecmp. This should fix the problem. Why only you see it is a mystery, though. Andreas will hopefully build a new glibc soon.
Created attachment 448618 [details] cache.tar.gz
glibc-2.12.90-13 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/glibc-2.12.90-13
glibc-2.12.90-13 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update glibc'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/glibc-2.12.90-13
glibc-2.12.90-14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update glibc'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/glibc-2.12.90-14
Yup, that fixes it. Thanks, Ulrich!
glibc-2.12.90-14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.