public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Roland Schwingel <Roland.Schwingel@onevision.com>
To: "Binutils" <binutils@sourceware.org>
Subject: LD: Invalid memory access when linking a dll (maybe Bug 29006 revisited)
Date: Tue, 10 May 2022 19:19:03 +0200	[thread overview]
Message-ID: <OF55448B10.6B442CE8-ONC125883E.00509B6E-C125883E.005F2C39@onevision.com> (raw)

Hi...

I am building C++20 code on windows and cross on linux for windows.

Unfortunately ld crashes on linking a dll on both windows and linux.There 
is a bug report from Sandro Mani describing maybe the same - or at least - 
a very similar problem.
(https://sourceware.org/bugzilla/show_bug.cgi?id=29006)
The issue got adressed by Nick Clifton who also added a patch to the issue

We are using binutils 2.38 (with and with out the fix of Nick) together 
with some self built GCC 11.2 and 11.3.But it seems it does not make a 
difference.

The bug does not happen always. The concrete circumstances are yet unclear 
to me. The invalid memory access may only happen when I link C++20 code 
compiled by GCC with debug informations (-g) when linking with -O3 (and no 
-g) it appears to work. I got it reproducable in about 10 different cases. 
Valgrind reports around 19110 errors by invalid memory access.

Invocation with valgrind of ld with the patch of nick already applied: 
valgrind 
/ovde_plugins/gcc11/mingwin/lib64/gcc/x86_64-w64-mingw32/11.3.0/../../../../x86_64-w64-mingw32/bin/ld 
-v 
  --sysroot=/ovde_plugins/gcc11/mingwin -m i386pep 
  --subsystem console --dll -Bdynamic -e DllMainCRTStartup 
--enable-auto-image-base 
  -o /tmp/parser_lib_g.dll 
/ovde_plugins/gcc11/mingwin/lib64/gcc/x86_64-w64-mingw32/11.3.0/../../../../x86_64-w64-mingw32/lib/../lib/dllcrt2.o 

 
/ovde_plugins/gcc11/mingwin/lib64/gcc/x86_64-w64-mingw32/11.3.0/crtbegin.o 

  <a bunch of -L params>
  /tmp/parser_lib_g.exp 
  -pie --image-base 0x15690000 --enable-auto-import 
  /tmp/parser_lib_dllmain.o /tmp/Parser.o /tmp/Parser_17020R.o <and some 
more .o files>
  --nxcompat --whole-archive -lxml_g -lovcore_g -lhelper_lib_g 
--no-whole-archive -lstdc++ 
  --as-needed -lgomp -luser32 -lkernel32 -lmingwthrd -lmingw32 -lgcc_s 
-lgcc -lmoldname -lmingwex -lmsvcrt -lkernel32 
  /ovde_plugins/gcc11/mingwin/lib64/gcc/x86_64-w64-mingw32/11.3.0/crtend.o

==23381==
GNU ld (GNU Binutils) 2.38
==23381== Invalid read of size 1
==23381==    at 0x508B434: vfprintf (in /lib64/libc-2.17.so)
==23381==    by 0x50B3E63: vasprintf (in /lib64/libc-2.17.so)
==23381==    by 0x50912F6: asprintf (in /lib64/libc-2.17.so)
==23381==    by 0x4432CE: make_runtime_pseudo_reloc (pe-dll.c:2663)
==23381==    by 0x443A81: pep_create_import_fixup (pe-dll.c:2838)
==23381==    by 0x432CA6: make_import_fixup (ei386pep.c:1129)
==23381==    by 0x43F8A5: pe_walk_relocs (pe-dll.c:1349)
==23381==    by 0x43FD95: pep_find_data_imports (pe-dll.c:1497)
==23381==    by 0x433674: gld_i386pep_after_open (ei386pep.c:1408)
==23381==    by 0x428FCB: ldemul_after_open (ldemul.c:65)
==23381==    by 0x41D9F2: lang_process (ldlang.c:8162)
==23381==    by 0x422440: main (ldmain.c:497)
==23381==  Address 0x95e2500 is 0 bytes inside a block of size 20 free'd
==23381==    at 0x4C2E10B: free (vg_replace_malloc.c:871)
==23381==    by 0x445199: pep_process_import_defs (pe-dll.c:3324)
==23381==    by 0x433648: gld_i386pep_after_open (ei386pep.c:1405)
==23381==    by 0x428FCB: ldemul_after_open (ldemul.c:65)
==23381==    by 0x41D9F2: lang_process (ldlang.c:8162)
==23381==    by 0x422440: main (ldmain.c:497)
==23381==  Block was alloc'd at
==23381==    at 0x4C306F1: malloc (vg_replace_malloc.c:380)
==23381==    by 0x51658B: xmalloc (xmalloc.c:149)
==23381==    by 0x5166BE: xstrdup (xstrdup.c:34)
==23381==    by 0x444ADB: pep_process_import_defs (pe-dll.c:3234)
==23381==    by 0x433648: gld_i386pep_after_open (ei386pep.c:1405)
==23381==    by 0x428FCB: ldemul_after_open (ldemul.c:65)
==23381==    by 0x41D9F2: lang_process (ldlang.c:8162)
==23381==    by 0x422440: main (ldmain.c:497)
==23381==
==23381== Invalid read of size 1
==23381==    at 0x50B83A0: _IO_default_xsputn (in /lib64/libc-2.17.so)
==23381==    by 0x508B472: vfprintf (in /lib64/libc-2.17.so)
==23381==    by 0x50B3E63: vasprintf (in /lib64/libc-2.17.so)
==23381==    by 0x50912F6: asprintf (in /lib64/libc-2.17.so)
==23381==    by 0x4432CE: make_runtime_pseudo_reloc (pe-dll.c:2663)
==23381==    by 0x443A81: pep_create_import_fixup (pe-dll.c:2838)
==23381==    by 0x432CA6: make_import_fixup (ei386pep.c:1129)
==23381==    by 0x43F8A5: pe_walk_relocs (pe-dll.c:1349)
==23381==    by 0x43FD95: pep_find_data_imports (pe-dll.c:1497)
==23381==    by 0x433674: gld_i386pep_after_open (ei386pep.c:1408)
==23381==    by 0x428FCB: ldemul_after_open (ldemul.c:65)
==23381==    by 0x41D9F2: lang_process (ldlang.c:8162)
==23381==  Address 0x95e2500 is 0 bytes inside a block of size 20 free'd
==23381==    at 0x4C2E10B: free (vg_replace_malloc.c:871)
==23381==    by 0x445199: pep_process_import_defs (pe-dll.c:3324)
==23381==    by 0x433648: gld_i386pep_after_open (ei386pep.c:1405)
==23381==    by 0x428FCB: ldemul_after_open (ldemul.c:65)
==23381==    by 0x41D9F2: lang_process (ldlang.c:8162)
==23381==    by 0x422440: main (ldmain.c:497)
==23381==  Block was alloc'd at
==23381==    at 0x4C306F1: malloc (vg_replace_malloc.c:380)
==23381==    by 0x51658B: xmalloc (xmalloc.c:149)
==23381==    by 0x5166BE: xstrdup (xstrdup.c:34)
==23381==    by 0x444ADB: pep_process_import_defs (pe-dll.c:3234)
==23381==    by 0x433648: gld_i386pep_after_open (ei386pep.c:1405)
==23381==    by 0x428FCB: ldemul_after_open (ldemul.c:65)
==23381==    by 0x41D9F2: lang_process (ldlang.c:8162)
==23381==    by 0x422440: main (ldmain.c:497)
==23381==
==23381== Invalid read of size 1
==23381==    at 0x50B83AE: _IO_default_xsputn (in /lib64/libc-2.17.so)
==23381==    by 0x508B472: vfprintf (in /lib64/libc-2.17.so)
==23381==    by 0x50B3E63: vasprintf (in /lib64/libc-2.17.so)
==23381==    by 0x50912F6: asprintf (in /lib64/libc-2.17.so)
==23381==    by 0x4432CE: make_runtime_pseudo_reloc (pe-dll.c:2663)
==23381==    by 0x443A81: pep_create_import_fixup (pe-dll.c:2838)
==23381==    by 0x432CA6: make_import_fixup (ei386pep.c:1129)
==23381==    by 0x43F8A5: pe_walk_relocs (pe-dll.c:1349)
==23381==    by 0x43FD95: pep_find_data_imports (pe-dll.c:1497)
==23381==    by 0x433674: gld_i386pep_after_open (ei386pep.c:1408)
==23381==    by 0x428FCB: ldemul_after_open (ldemul.c:65)
==23381==    by 0x41D9F2: lang_process (ldlang.c:8162)
==23381==  Address 0x95e2502 is 2 bytes inside a block of size 20 free'd
==23381==    at 0x4C2E10B: free (vg_replace_malloc.c:871)
==23381==    by 0x445199: pep_process_import_defs (pe-dll.c:3324)
==23381==    by 0x433648: gld_i386pep_after_open (ei386pep.c:1405)
==23381==    by 0x428FCB: ldemul_after_open (ldemul.c:65)
==23381==    by 0x41D9F2: lang_process (ldlang.c:8162)
==23381==    by 0x422440: main (ldmain.c:497)
==23381==  Block was alloc'd at
==23381==    at 0x4C306F1: malloc (vg_replace_malloc.c:380)
==23381==    by 0x51658B: xmalloc (xmalloc.c:149)
==23381==    by 0x5166BE: xstrdup (xstrdup.c:34)
==23381==    by 0x444ADB: pep_process_import_defs (pe-dll.c:3234)
==23381==    by 0x433648: gld_i386pep_after_open (ei386pep.c:1405)
==23381==    by 0x428FCB: ldemul_after_open (ldemul.c:65)
==23381==    by 0x41D9F2: lang_process (ldlang.c:8162)
==23381==    by 0x422440: main (ldmain.c:497)
==23381==
==23381== Invalid read of size 1
==23381==    at 0x508B434: vfprintf (in /lib64/libc-2.17.so)
==23381==    by 0x50B3E63: vasprintf (in /lib64/libc-2.17.so)
==23381==    by 0x50912F6: asprintf (in /lib64/libc-2.17.so)
==23381==    by 0x4436C3: pe_create_runtime_relocator_reference 
(pe-dll.c:2754)
==23381==    by 0x443AD1: pep_create_import_fixup (pe-dll.c:2844)
==23381==    by 0x432CA6: make_import_fixup (ei386pep.c:1129)
==23381==    by 0x43F8A5: pe_walk_relocs (pe-dll.c:1349)
==23381==    by 0x43FD95: pep_find_data_imports (pe-dll.c:1497)
==23381==    by 0x433674: gld_i386pep_after_open (ei386pep.c:1408)
==23381==    by 0x428FCB: ldemul_after_open (ldemul.c:65)
==23381==    by 0x41D9F2: lang_process (ldlang.c:8162)
==23381==    by 0x422440: main (ldmain.c:497)
==23381==  Address 0x95e2500 is 0 bytes inside a block of size 20 free'd
==23381==    at 0x4C2E10B: free (vg_replace_malloc.c:871)
==23381==    by 0x445199: pep_process_import_defs (pe-dll.c:3324)
==23381==    by 0x433648: gld_i386pep_after_open (ei386pep.c:1405)
==23381==    by 0x428FCB: ldemul_after_open (ldemul.c:65)
==23381==    by 0x41D9F2: lang_process (ldlang.c:8162)
==23381==    by 0x422440: main (ldmain.c:497)
==23381==  Block was alloc'd at
==23381==    at 0x4C306F1: malloc (vg_replace_malloc.c:380)
==23381==    by 0x51658B: xmalloc (xmalloc.c:149)
==23381==    by 0x5166BE: xstrdup (xstrdup.c:34)
==23381==    by 0x444ADB: pep_process_import_defs (pe-dll.c:3234)
==23381==    by 0x433648: gld_i386pep_after_open (ei386pep.c:1405)
==23381==    by 0x428FCB: ldemul_after_open (ldemul.c:65)
==23381==    by 0x41D9F2: lang_process (ldlang.c:8162)
==23381==    by 0x422440: main (ldmain.c:497)
==23381==
==23381==
==23381== HEAP SUMMARY:
==23381==     in use at exit: 83,040,828 bytes in 25,511 blocks
==23381==   total heap usage: 96,735 allocs, 71,224 frees, 122,050,867 
bytes allocated
==23381==
==23381== LEAK SUMMARY:
==23381==    definitely lost: 2,432,172 bytes in 1,940 blocks
==23381==    indirectly lost: 194,424 bytes in 1,075 blocks
==23381==      possibly lost: 0 bytes in 0 blocks
==23381==    still reachable: 80,414,232 bytes in 22,496 blocks
==23381==         suppressed: 0 bytes in 0 blocks
==23381== Rerun with --leak-check=full to see details of leaked memory
==23381==
==23381== For lists of detected and suppressed errors, rerun with: -s
==23381== ERROR SUMMARY: 19110 errors from 4 contexts (suppressed: 0 from 
0)

It is maybe related to C++20. I do not have problems linking 
C/C++17/ObjectiveC code. And only when linking code compiled with -g.

From what I understand all symbols are processed in 
pep_process_import_defs() from pe_dll.c. The symbols are temporarily 
stored in the static variable dll_symname (pe-dll.c:3234) and afterwards 
freed (pe-dll.c:3324) but dll_symname remains to an already freed pointer 
afterwards. in make_runtime_pseudo_reloc() (pe-dll.c:2663) this variable 
is by then accessed. What should be the right content of dll_symname in 
this case?

Hope this can help to track down the problem.

Roland

-----------------------------------------------------------------------------------------------------
Roland Schwingel, Head of Research & Development
OneVision Software AG, Dr. Leo-Ritter-Str. 9, 93049 Regensburg, Germany
Phone: +49 941 78004 0 --- email: roland.schwingel@onevision.com
-----------------------------------------------------------------------------------------------------
This email may contain trade secrets or other confidential information. If 
you have received this email inadvertently, please let us know by reply 
and then delete the email entirely from your system. You are explicitly 
prohibited from reviewing, copying, and/or distributing the email to third 
parties.
Sitz der Gesellschaft: Regensburg; Handelsregister: HRB 8015, Amtsgericht 
Regensburg; Vorstand: Hussein Khalil; Vorsitzender des Aufsichtsrats: 
Michael Abels


             reply	other threads:[~2022-05-10 17:19 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-10 17:19 Roland Schwingel [this message]
2022-05-11 12:49 ` Alan Modra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=OF55448B10.6B442CE8-ONC125883E.00509B6E-C125883E.005F2C39@onevision.com \
    --to=roland.schwingel@onevision.com \
    --cc=binutils@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).