Bug 470260 - Valgrind crashes when run with --multi
Summary: Valgrind crashes when run with --multi
Status: CONFIRMED
Alias: None
Product: valgrind
Classification: Developer tools
Component: general (show other bugs)
Version: unspecified
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Julian Seward
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-05-25 14:33 UTC by Alexandra Hajkova
Modified: 2023-05-25 15:17 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
reproducer (738 bytes, text/x-csrc)
2023-05-25 14:33 UTC, Alexandra Hajkova
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alexandra Hajkova 2023-05-25 14:33:24 UTC
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)
Comment 1 Mark Wielaard 2023-05-25 15:17:54 UTC
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.