https://bugs.kde.org/show_bug.cgi?id=381162
--- Comment #7 from Ivo Raisr <[email protected]> --- I concur. I hope this will shed some light for a mysterious bug I see on x86/Solaris (not amd64/Solaris) which manifests in the following debug output printed for almost all gdbserver_tests: vex iropt: 4 x unrolling (25 sts -> 100 sts) vex iropt: 2 x unrolling (50 sts -> 100 sts) vex iropt: 2 x unrolling (34 sts -> 68 sts) vex iropt: fold_Expr: no ident rule for: 32HLto64(t47,t47) vex iropt: 8 x unrolling (13 sts -> 104 sts) vex iropt: 2 x unrolling (56 sts -> 112 sts) vex iropt: 8 x unrolling (14 sts -> 112 sts) vex iropt: 2 x unrolling (57 sts -> 114 sts) vex iropt: 2 x unrolling (47 sts -> 94 sts) vex iropt: 2 x unrolling (33 sts -> 66 sts) vex iropt: fold_Expr: no ident rule for: 32HLto64(t68,t68) vex iropt: fold_Expr: no ident rule for: 32HLto64(t62,t62) vex iropt: fold_Expr: no ident rule for: 32HLto64(t66,t66) vex iropt: fold_Expr: no ident rule for: 32HLto64(t57,t57) vex iropt: 2 x unrolling (39 sts -> 78 sts) vex iropt: 2 x unrolling (33 sts -> 66 sts) vex iropt: 2 x unrolling (57 sts -> 114 sts) vex iropt: 2 x unrolling (39 sts -> 78 sts) vex iropt: IRStmt_Exit became unconditional vex iropt: IRStmt_Exit became unconditional vex iropt: 2 x unrolling (32 sts -> 64 sts) vex iropt: 2 x unrolling (44 sts -> 88 sts) vex iropt: IRStmt_Exit became unconditional vex iropt: fold_Expr: no ident rule for: 32HLto64(t118,t118) vex iropt: 2 x unrolling (33 sts -> 66 sts) This is printed only for a brief duration and I can reproduce it outside the 'regtest' harness. For example with nlvgdbsigqueue, following GDB commands in nlvgdbsigqueue.stdinB.gdb, it is printed only after I hit "continue": ../vg-in-place --tool=none --vgdb=yes --vgdb-error=0 --vgdb-prefix=./vgdb-prefix-nlvgdbsigqueue ./sleepers 1000000000 1000000000 1 BSBSBSBS 1 ==9979== Nulgrind, the minimal Valgrind tool ==9979== Copyright (C) 2002-2017, and GNU GPL'd, by Nicholas Nethercote. ==9979== Using Valgrind-3.14.0.SVN and LibVEX; rerun with -h for copyright info ==9979== Command: ./sleepers 1000000000 1000000000 1 BSBSBSBS 1 ==9979== ==9979== (action at startup) vgdb me ... ==9979== ==9979== TO DEBUG THIS PROCESS USING GDB: start GDB like this ==9979== /path/to/gdb ./sleepers ==9979== and then give GDB the following command ==9979== target remote | /export/home/tester1/valgrind-32/gdbserver_tests/../.in_place/../../bin/vgdb --vgdb-prefix=./vgdb-prefix-nlvgdbsigqueue --pid=9979 ==9979== --pid is optional if only one valgrind process is running ==9979== [here all the signals are queued as described in nlvgdbsigqueue.stdinB.gdb] [then do "continue" in GDB] vex iropt: 4 x unrolling (20 sts -> 80 sts) vex iropt: 2 x unrolling (41 sts -> 82 sts) vex iropt: 4 x unrolling (29 sts -> 116 sts) vex iropt: 2 x unrolling (38 sts -> 76 sts) vex iropt: 8 x unrolling (12 sts -> 96 sts) vex iropt: 2 x unrolling (32 sts -> 64 sts) vex iropt: 8 x unrolling (13 sts -> 104 sts) vex iropt: 4 x unrolling (30 sts -> 120 sts) vex iropt: 2 x unrolling (39 sts -> 78 sts) vex iropt: 4 x unrolling (16 sts -> 64 sts) vex iropt: 8 x unrolling (15 sts -> 120 sts) vex iropt: 2 x unrolling (34 sts -> 68 sts) vex iropt: not unrolling (75 sts) vex iropt: 4 x unrolling (29 sts -> 116 sts) vex iropt: 4 x unrolling (16 sts -> 64 sts) vex iropt: 8 x unrolling (15 sts -> 120 sts) vex iropt: 4 x unrolling (23 sts -> 92 sts) vex iropt: IRStmt_Exit became unconditional vex iropt: 8 x unrolling (13 sts -> 104 sts) vex iropt: 8 x unrolling (12 sts -> 96 sts) vex iropt: IRStmt_Exit became unconditional vex iropt: 2 x unrolling (35 sts -> 70 sts) loops/sleep_ms/burn/threads_spec/affinity: 1000000000 1000000000 1 BSBSBSBS 1 vex iropt: IRStmt_Exit became unconditional vex iropt: 2 x unrolling (50 sts -> 100 sts) vex iropt: IRStmt_Exit became unconditional vex iropt: 2 x unrolling (31 sts -> 62 sts) vex iropt: 2 x unrolling (34 sts -> 68 sts) vex iropt: 8 x unrolling (13 sts -> 104 sts) vex iropt: 2 x unrolling (50 sts -> 100 sts) Brussels ready to sleep and/or burn London ready to sleep and/or burn Petaouchnok ready to sleep and/or burn main ready to sleep and/or burn Unfortunately I cannot attach to the main Valgrind process with gdb to watch who has supposedly mistakenly overwritten vex_control.iropt_verbosity. Because by that time procfs agent thread is created in the process and gdb is confused about it and crashes. -- You are receiving this mail because: You are watching all bug changes.
