Created attachment 129177 [details] log file SUMMARY valgrind fails with an internal error: vex: the `impossible' happened: expr_is_guardable: unhandled expr vex storage: T total 993007680 bytes allocated vex storage: P total 496 bytes allocated valgrind: the 'impossible' happened: LibVEX called failure_exit(). host stacktrace: ==71737== at 0x5803FDC7: ??? (in /usr/libexec/valgrind/memcheck-x86-linux) ... ==71737== by 0x580FA469: ??? (in /usr/libexec/valgrind/memcheck-x86-linux) sched status: running_tid=1 Thread 1: status = VgTs_Runnable (lwpid 71737) ==71737== at 0x83C6036: cnv_double_to_string (in /u/william/linux-dvl/cpag/cpag) client stack range: [0xFEC2C000 0xFEC37FFF] client SP: 0xFEC32320 valgrind stack range: [0x883AA000 0x884A9FFF] top usage: 6104 of 1048576 STEPS TO REPRODUCE 1. It happens every time when I run my application. OBSERVED RESULT Valgrind aborts with an 'impossible' error. EXPECTED RESULT Valgrind does not abort. SOFTWARE/OS VERSIONS Fedora 31, kernel 5.6.15-200.fc31.x86_64 It is a 64 bit OS, but my application is 32 bit. valgrind-3.16.0-1.fc31.i686 ADDITIONAL INFORMATION I have been using valgrind for years on this application, and it never gave an 'impossible' error before. Google and searching in bugzilla did not find 'expr_is_guardable', so this might be a new problem in valgrind 3.16.0. Is this a known problem? Should I try to make a small example? (The 'cnv_double_to_string' function just calls sprintf and hasn't been touched for years.) Should I try to do a bisection on valgrind?
This is the new &&-idiom-recovery machinery in 3.16.0. Looks like I didn't test it well enough on x86_32 (sigh). It should be trivial to fix. You unfortunately cut off the most important bit of the failure message. What was printed immediately prior to "valgrind fails with an internal error:" ? That is to say: what was printed by the ppIRExpr call in default: vex_printf("\n"); ppIRExpr(e); vex_printf("\n"); vpanic("expr_is_guardable: unhandled expr"); in expr_is_guardable() ?
Err, ignore that last comment. I just discovered you attached a complete log file. /me gets some more coffee. Let me see if I can repro this locally. In principle this is easy to fix, but I'd like to be able to test the fix.
Created attachment 129180 [details] A possible fix Try this. It fixes the problem for me.
Thanks! The patch fixed the problem for me.
This was fixed by: commit 6aa4f7e7e76b40c183fb29650540d119ce1b4a4a Author: Julian Seward <jseward@acm.org> Date: Thu Jun 11 09:01:52 2020 +0200 expr_is_guardable, stmt_is_guardable, add_guarded_stmt_to_end_of: handle GetI/PutI cases. This fixes #422715. Which was also put in the 3.16.16 release.