| Summary: | Valgrind crashes when run with --multi | ||
|---|---|---|---|
| Product: | [Developer tools] valgrind | Reporter: | Alexandra Hajkova <ahajkova> |
| Component: | general | Assignee: | Julian Seward <jseward> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | mark |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Attachments: | reproducer | ||
I can replicate this with valgrind-3.21.0-4.fc38.x86_64. It looks like the inferior function call gets something confused. Either the current thread or stack pointer depending on where we try the print strlen call. |
Created attachment 159252 [details] reproducer STEPS TO REPRODUCE 1. gcc -g -o ex example.c 2. gdb -ex 'set remote exec-file ./ex' -ex 'set sysroot /' -ex 'target extended-remote | vgdb --multi --vargs -q' ./ex 3. r Starting program: /root/valgrind/ex relaying data between gdb and process 533320 Loaded /usr/share/gdb/auto-load/valgrind-monitor.py Type "help valgrind" for more info. ==533320== Conditional jump or move depends on uninitialised value(s) ==533320== at 0x4011B3: main (example.c:29) ==533320== ==533320== (action on error) vgdb me ... Program received signal SIGTRAP, Trace/breakpoint trap. 0x00000000004011b3 in main () at example.c:29 29 if (s.flag1 || s.flag2) Missing separate debuginfos, use: dnf debuginfo-install glibc-2.37.9000-9.fc39.x86_64 4. c (gdb) c Continuing. ==533320== Continuing ... ==533320== Syscall param write(buf) points to uninitialised byte(s) ==533320== at 0x4963FB4: write (write.c:26) .... Program received signal SIGTRAP, Trace/breakpoint trap. 0x0000000004963fb4 in write () from /lib64/libc.so.6 5. print (int)strlen("flag1 value: ") 6. c (gdb) c Continuing. valgrind: m_syswrap/syswrap-main.c:2136 (vgPlain_client_syscall): Assertion 'sci->status.what == SsIdle' failed. host stacktrace: ==533303== at 0x580439FA: show_sched_status_wrk (m_libcassert.c:406) ==533303== by 0x58043B2F: report_and_quit (m_libcassert.c:477) ==533303== by 0x58043CC5: vgPlain_assert_fail (m_libcassert.c:543) ==533303== by 0x580A41BC: vgPlain_client_syscall (syswrap-main.c:2136) ==533303== by 0x5809F572: handle_syscall (scheduler.c:1206) ==533303== by 0x580A1688: vgPlain_scheduler (scheduler.c:1552) ==533303== by 0x580E9437: thread_wrapper (syswrap-linux.c:102) ==533303== by 0x580E9437: run_a_thread_NORETURN (syswrap-linux.c:155) sched status: running_tid=1 Thread 1: status = VgTs_Runnable syscall 1 (lwpid 533303) ==533303== at 0x4963FB4: write (write.c:26) ==533303== by 0x48E6804: _IO_file_write@@GLIBC_2.2.5 (fileops.c:1180) ==533303== by 0x48E49BE: new_do_write (fileops.c:448) ==533303== by 0x48E5820: _IO_do_write@@GLIBC_2.2.5 (fileops.c:425) ==533303== by 0x48E505F: _IO_file_close_it@@GLIBC_2.2.5 (fileops.c:135) ==533303== by 0x48D8C12: fclose@@GLIBC_2.2.5 (iofclose.c:53) ==533303== by 0x401230: main (example.c:36) client stack range: [0x1FFEFFE000 0x1FFF000FFF] client SP: 0x1FFEFFFCE8 valgrind stack range: [0x1002BAA000 0x1002CA9FFF] top usage: 10144 of 1048576 Note: see also the FAQ in the source distribution. It contains workarounds to several common problems. In particular, if Valgrind aborted or crashed after identifying problems in your program, there's a good chance that fixing those problems will prevent Valgrind aborting or crashing, especially if it happened in m_mallocfree.c. If that doesn't help, please report this bug to: www.valgrind.org In the bug report, send all the above text, the valgrind version, and what OS and version you are using. Thanks. Program terminated with signal 0, Signal 0. The program no longer exists. SOFTWARE/OS VERSIONS kernel-6.2.0-0.rc3.20230113gitd9fc1511728c.28.fc38.x86_64 gdb-13.1-5.fc39.x86_64 valgrind-3.21.0-3.fc39.x86_64 Fedora Linux 38 (Rawhide Prerelease)