Red Hat Bugzilla – Bug 89143
One reason of run-time error while building of glibc with Intel Proton compiler.
Last modified: 2016-11-24 10:23:54 EST
Description of problem:
I try to build glibc with Intel compiler. I have run-time error "Segmentation
fault" and while analyzed it I found the error in glibc text. The error is
We have run-time error "Segmentation fault" while building of glibc package on
the step "# Generate the rpcsvc headers with rpcgen". Appropriate
rule "$(objpfx)rpcsvc/%.stmp: " is positioned in sunrpc/Makefile.
This error happens when dynamic linker (ld.so) works and "case 0:" in
function "fixup" is. I give appropriate text after the string 101 in dl-
101 case 0:
102 result = INTUSE(_dl_lookup_symbol) (strtab + sym->st_name, l, &sym,
107 /* Currently result contains the base load address (or link map)
108 of the object that defines sym. Now add in the symbol
109 offset. */
110 value = (sym ? LOOKUP_VALUE_ADDRESS (result) + sym->st_value : 0);
If function "_dl_lookup_symbol" ( in dl-lookup.c ) returns "0" it always
returns sym = 0, too. You can see that &sym is third parameter of this
function. It happens due to the string 250 in dl-lookup.c( *ref = NULL;).
As a result we have value = 0 (see string 110 in above text) and this value
function fixup returns. But function fixup can not return zero at all.
The address returned is used for jumping. I give glibc text where fixup called
( from /sysdeps/i386/dl-mashine.h ):
220 call fixup # Call resolver.\n\
221 popl %edx # Pop the parameters\n\
222 popl %ecx\n\
223 popl %edx # Get register content back.\n\
224 popl %ecx\n\
225 xchgl %eax, (%esp) # Get %eax contents end store function
226 ret $8 # Jump to function address.\n\
Run-time error "Segmentation fault" happens on last operator "ret $8" from
Version-Release number of selected component (if applicable):
While rpm build glibc with Intel compiler.
Steps to Reproduce:
1. It is difficult. See description.
Solve your problems yourself. We are not going to help you using your compiler.
This bug is not critical for Intel compiler. It is a real bug in glibc text and
knowledge about it is very useful for glibc quality. Report should be
reassigned to the interested person.
There is no proof above there is a bug in glibc. What you described is certainly
not where the bug happens. It looks (although you haven't bothered to mention
which symbol is being looked up) like a call to weak undefined symbol not defined anywhere,
which suggest a compiler bug.
As said above, we are certainly not going to debug bugs in your compiler.
If you find a real glibc bug, fine, we'll look at it. But you haven't shown anything
You are right that undefined symbol seems to be a compiler bug.
But the behavior when symbols are carefully checked and then it ends with a
jump to 0 seems to be a real glibc bug, isn't it?