smcc
commented
4 years ago That kind of stack backtrace generally comes from using a null pointer as a function pointer.
What this sounds most similar to to me is an issue with the VEX build process that we've had before, which we tried to address for instance here:
The argument "dis_instr_fn" to bb_to_IR is supposed to be a function pointer pointing at an architecture-specific disassembly function. But it looks like a null pointer is getting passed, which leads to the crash you see. For FuzzBALL's purposes you want to have a version of the VEX library that supports all three of the architectures that FuzzBALL does, but this is a bit different from the way VEX is used in Valgrind, which only supports host and guest architectures matching. In more recent versions of VEX, this is achieved by linking in the multiarch_main_main compilation unit instead of main_main. The above-referenced patch changes Makefile-gcc to do this in making a libvex.a library; the more complex autotools-based build process used in Valgrind apparently instead creates a separate libvexmultiarch-
So my guess is that this failure is triggered by building VEX in something other than one of our tested and recommended ways (step 2 in the INSTALL file). For instance just copying a libvex.a compiled from the Valgrind build process will probably not work with recent VEX versions because of this issue. If you provide more details about exactly how you compiled VEX, we can probably reproduce the problem and/or suggest what you should do differently.
When I run Fuzzball,fter entering ./fuzzball -linux-syscalls -skip-call-ret-symbol 0x080485a6=n -trace-stopping simple -- ./simple 1 in the terminal,I found the problem “Segmentation fault (core dumped)”,I run my test under GDB,I got the information shown on the picture.I don't know how to solve it.