Your message dated Sat, 09 Aug 2025 01:08:41 -0400 with message-id <[email protected]> and subject line Re: Bug#1012311: libc6: invalid debug symbol for optind has caused the Debian Bug report #1012311, regarding libc6: invalid debug symbol for optind to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 1012311: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1012311 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: libc6 Version: 2.31-13+deb11u3 Severity: normal Dear Maintainer, Here is a simple example program: #include <unistd.h> int main() { optind = 2; } I compiled it with 'gcc -g -O0' and ran it through gdb: (gdb) b main Breakpoint 1 at 0x1129: file main.c, line 5. (gdb) r Starting program: /home/marionm/test/optind/a.out Breakpoint 1, main () at main.c:5 5 optind = 2; (gdb) n 6 } (gdb) p optind $1 = 1 (gdb) p &optind $2 = (int *) 0x7ffff7fa1344 <optind> (gdb) disassemble Dump of assembler code for function main: 0x0000555555555125 <+0>: push %rbp 0x0000555555555126 <+1>: mov %rsp,%rbp 0x0000555555555129 <+4>: movl $0x2,0x2ef5(%rip) # 0x555555558028 <optind@GLIBC_2.2.5> 0x0000555555555133 <+14>: mov $0x0,%eax => 0x0000555555555138 <+19>: pop %rbp 0x0000555555555139 <+20>: ret End of assembler dump. (gdb) We can see that the address used by GDB when accessing 'optind' is not the same as the one present in the assembly code (0x7ffff7fa1344 vs 0x555555558028). When running this experiment on Debian with the packaged gdb version 10 and 11, we get the unexpected behavior described above. The same test run on Fedora with gdb version 12 results in the expected behavior of seeing the same address on both sides. I originally made the silly mistake of believing that 'optind' provided the index of the current option being processed, while it actually contains the next option to be processed. When debugging, gdb would show me a value of 1 in optind (as I wrongly expected) instead of the real value of 3, which led to a difficult debugging experience. This issue might also be caused by gdb instead of libc but I don't have a deep enough understanding of the problem to ensure one or the other. -- System Information: Debian Release: 11.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.16.0-0.bpo.4-amd64 (SMP w/12 CPU threads; PREEMPT) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libc6 depends on: ii libcrypt1 1:4.4.18-4 ii libgcc-s1 10.2.1-6 Versions of packages libc6 recommends: ii libidn2-0 2.3.0-5 pn libnss-nis <none> pn libnss-nisplus <none> Versions of packages libc6 suggests: ii debconf [debconf-2.0] 1.5.77 pn glibc-doc <none> ii libc-l10n 2.31-13+deb11u3 ii locales 2.31-13+deb11u3 -- debconf information: glibc/kernel-not-supported: glibc/disable-screensaver: glibc/upgrade: true glibc/restart-services: libraries/restart-without-asking: false glibc/kernel-too-old: glibc/restart-failed:
--- End Message ---
--- Begin Message ---On Friday, June 03 2022, Mathis MARION wrote: > Here is a simple example program: > > > #include <unistd.h> > > int main() > { > optind = 2; > } > > > I compiled it with 'gcc -g -O0' and ran it through gdb: > > > (gdb) b main > Breakpoint 1 at 0x1129: file main.c, line 5. > (gdb) r > Starting program: /home/marionm/test/optind/a.out > > Breakpoint 1, main () at main.c:5 > 5 optind = 2; > (gdb) n > 6 } > (gdb) p optind > $1 = 1 > (gdb) p &optind > $2 = (int *) 0x7ffff7fa1344 <optind> > (gdb) disassemble > Dump of assembler code for function main: > 0x0000555555555125 <+0>: push %rbp > 0x0000555555555126 <+1>: mov %rsp,%rbp > 0x0000555555555129 <+4>: movl $0x2,0x2ef5(%rip) # > 0x555555558028 <optind@GLIBC_2.2.5> > 0x0000555555555133 <+14>: mov $0x0,%eax > => 0x0000555555555138 <+19>: pop %rbp > 0x0000555555555139 <+20>: ret > End of assembler dump. > (gdb) > > > We can see that the address used by GDB when accessing 'optind' is not the > same > as the one present in the assembly code (0x7ffff7fa1344 vs 0x555555558028). Hi, As described by Aurelien, this problem has been fixed a while ago. I can't reproduce it anymore with GDB 16.3. --8<---------------cut here---------------start------------->8--- (gdb) p optind $1 = 2 (gdb) p &optind $2 = (int *) 0x555555558010 <optind@GLIBC_2.2.5> (gdb) disassemble Dump of assembler code for function main: 0x0000555555555129 <+0>: push %rbp 0x000055555555512a <+1>: mov %rsp,%rbp 0x000055555555512d <+4>: movl $0x2,0x2ed9(%rip) # 0x555555558010 <optind@GLIBC_2.2.5> 0x0000555555555137 <+14>: mov $0x0,%eax => 0x000055555555513c <+19>: pop %rbp 0x000055555555513d <+20>: ret End of assembler dump. --8<---------------cut here---------------end--------------->8--- Therefore, I'm closing the bug. Thanks, -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible https://sergiodj.net/
signature.asc
Description: PGP signature
--- End Message ---
