Segmentation fault (2.1.2) about capstone HOT 30 CLOSED

On Thu, Apr 10, 2014 at 11:55 AM, Anton Bolshakov
[email protected]:

I've compiled test binaries with specific options:
http://pastebin.com/BxddKQSd

All test* binaries crashes with "segmentation fault" error message.
Still need to investigate what's going on here

this is interesting. can you just compile, install & run from source to see
if there is the same problem?

make; sudo make install; ./tests/test

from capstone.

No, there is no crash with default settings.

from capstone.

my environment variables during compilation:
http://pastebin.com/Q5t0mFck

from capstone.

I'm getting closer to the problem. It has something with shared library.

From command line:

cc -fPIC -O3 -Wall -I../include -L..  test.o -O3 -Wall -lcapstone -o test

from my env:

cc -march=core2 -mtune=generic -O2 -pipe -fPIC -O3 -Wall -Iinclude -DUSE_SYS_DYN_MEM -DCAPSTONE_HAS_ARM -DCAPSTONE_HAS_ARM64 -DCAPSTONE_HAS_MIPS -DCAPSTONE_HAS_POWERPC -DCAPSTONE_HAS_X86 -fPIC -O3 -Wall -I../include -L.. -Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu -shared -Wl,-soname,libcapstone.so.2 test.o -O3 -Wall -lcapstone -o test

it works fine if I drop "-shared -Wl,-soname,libcapstone.so.2"

from capstone.

yes, starting from 2.1.2, Capstone has versioning library setup, and
libcapstone.so is linked to libcapstone.so.2

it is easy to fix for your Gentoo package, i guess.

thanks.

On Thu, Apr 10, 2014 at 12:40 PM, Anton Bolshakov
[email protected]:

I think I found a problem. It hasn't been linked with capstone.so.2:

ldd ../../../image/usr/share/capstone/tests/test
linux-vdso.so.1 (0x00007fff6faf1000)
libc.so.6 => /lib64/libc.so.6 (0x00007fafd2eda000)
/lib64/ld-linux-x86-64.so.2 (0x00007fafd34bd000)
blshkv@pt /var/tmp/portage/dev-util/capstone-2.1.2/work/capstone-2.1.2/tests $ ldd test
linux-vdso.so.1 (0x00007fff49ffe000)
libcapstone.so.2 => /usr/lib64/libcapstone.so.2 (0x00007f92484e0000)
libc.so.6 => /lib64/libc.so.6 (0x00007f9248138000)
/lib64/ld-linux-x86-64.so.2 (0x00007f9248907000)

Reply to this email directly or view it on GitHubhttps://github.com//issues/92#issuecomment-40042467
.

from capstone.

I believe the error is in the Makefile. As you can see compilation variables from the main section are getting passed to /tests/Makefile file in "$(MAKE) -C tests" line

from capstone.

why?..

from capstone.

what do you mean? is this bug not solved yet? i think it was, so can you
try the "next" branch to confirm it?

On Thu, May 8, 2014 at 10:52 PM, Anton Bolshakov
[email protected]:

why?..

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/92#issuecomment-42559345
.

from capstone.

I don't see any related changes so I don't think it's fixed.
Again, the problem is with the environment variables. They are getting inherited from the main Makefile as per my previous comment. I have no idea why it's not happening when it's called from the command line.
Basically, the simple workaround for gentoo is to remove that call ($MAKE -C tests) and call it manually: make && cd tests && make (that will reset the variables)

from capstone.

hmm this is strange. too bad i dont have any Gentoo system to test this.

from capstone.

It's totally make sense actually. I even tried to call it with "-C -e tests" in attempt to reset variables but it cleans up everything.
So I suggest to leave the bug open until someone would come up with the patch because other distros might hit this bug soon or later too

from capstone.

I guess it is due to the LDFLAGS is passed down from the parent. Could you try adding one line to Makefile of test LDFLAGS = ?

from capstone.

http://www.gnu.org/software/make/manual/html_node/Variables_002fRecursion.html#Variables_002fRecursion
"Except by explicit request, make exports a variable only if it is either defined in the environment initially or set on the command line"

Yes! "LDFLAGS = " helped. Not sure what would be the proper solution here

from capstone.

Anton, can you confirm that this problem is solved in the "next" branch?

thanks.

from capstone.

so ok, it compiles and runs now, however it raises QA warning for obvious reason now:

 * QA Notice: Files built without respecting LDFLAGS have been detected
 *  Please include the following list of files in your report:
 * /usr/share/capstone/tests/test
 * /usr/share/capstone/tests/test_detail
 * /usr/share/capstone/tests/test_skipdata
 * /usr/share/capstone/tests/test_arm
 * /usr/share/capstone/tests/test_detail.static
 * /usr/share/capstone/tests/test.static
 * /usr/share/capstone/tests/test_skipdata.static
 * /usr/share/capstone/tests/test_arm.static
 * /usr/share/capstone/tests/test_arm64
 * /usr/share/capstone/tests/test_mips
 * /usr/share/capstone/tests/test_ppc
 * /usr/share/capstone/tests/test_sparc
 * /usr/share/capstone/tests/test_arm64.static
 * /usr/share/capstone/tests/test_mips.static
 * /usr/share/capstone/tests/test_ppc.static
 * /usr/share/capstone/tests/test_sparc.static
 * /usr/share/capstone/tests/test_systemz
 * /usr/share/capstone/tests/test_x86
 * /usr/share/capstone/tests/test_systemz.static
 * /usr/share/capstone/tests/test_x86.static

Discussed in #57

from capstone.

As a workaround, you might want to save LDFLAGS variable in the main Makefile and recover it right before calling "($MAKE -C tests)"

Alternately, you can create a new variable MY_LDFLAGS = LDFLAGS, make all necessary modifications to it and then call:

line 385: $(CC) $(MY_LDFLAGS) $(LIBOBJ) -o $(LIBRARY)

from capstone.

hmm i dont get it: we are having this in tests/Makefile

LDFLAGS = -L$(LIBDIR)

why it says: "Files built without respecting LDFLAGS have been detected"?

what is the meaning of "respecting LDFLAGS"?

thanks.

from capstone.

It means that you are overwriting the environment value of ldflags. Use += or ?=

On 10 May 2014, at 09:33, Nguyen Anh Quynh [email protected] wrote:

hmm i dont get it: we are having this in tests/Makefile

LDFLAGS = -L$(LIBDIR)

why it says: "Files built without respecting LDFLAGS have been detected"?

what is the meaning of "respecting LDFLAGS"?

thanks.
—
Reply to this email directly or view it on GitHub.

from capstone.

Anton, can you pull the "next" branch again to see if the latest commit
solves your issue?

thanks.

from capstone.

nop, not fixed. You overwrite my LDFLAGS which Gentoo provides via env variables.

Here is what happening:

Makefile:
LDFLAGS += (including my flags)
tests/Makefiels
LDFLAGS = (excluding my flags)

from capstone.

hard to test my fix without a Gentoo machine. can you send a pull request
for this?

thanks.

from capstone.

That's weird, I think testing should be standalone from any other stuff and thus make no sense to have += on those flags. Maybe we should really do cd tests && make to ensure no dependency from the compilation of the library is propagating to the compilation of the test.

from capstone.

Here is the fix to give you an idea. I've saved the flags and recovered them before the call of the second /tests make.

from capstone.

Anton, there is a new branch "gentoo" attempting to fix your issue. can you
confirm if the problem is solved?

https://github.com/aquynh/capstone/tree/gentoo

thanks.

from capstone.

Ha! No, you can't do "cd" inside of Makefile because it does not recover LDFAGS which you modified for capstone library specifically. So segfault is back again:
http://pastebin.com/dq8dZyEs

from capstone.

above you said "cd tests && make" was an workaround, and now this does exactly that, but segfault still happens?

any idea on exactly what is the reason of this crash issue?

from capstone.

I think the main problem is that the test* files are not getting linked with libpcastone.so.2 file.
try to recompile it with the following (I mentioned above)

cc -pipe -fPIC -O3 -Wall -Iinclude -DUSE_SYS_DYN_MEM -DCAPSTONE_HAS_ARM -DCAPSTONE_HAS_ARM64 -DCAPSTONE_HAS_MIPS -DCAPSTONE_HAS_POWERPC -DCAPSTONE_HAS_X86 -fPIC -O3 -Wall -I../include -L.. -Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu -shared -Wl,-soname,libcapstone.so.2 test.o -O3 -Wall -lcapstone -o test

ldd output:

        linux-vdso.so.1 (0x00000342a0b84000)
        libc.so.6 => /lib64/libc.so.6 (0x00000342a05a1000)
        /lib64/ld-linux-x86-64.so.2 (0x00000342a0b85000)

There is at least soname variable which should not be there

from capstone.

Vu just got a new fix. can you pull from "gentoo", and try again?

thanks.

On Wed, May 14, 2014 at 1:01 PM, Anton Bolshakov
[email protected]:

I think the main problem is that the test* files are not getting linked
with libpcastone.so.2 file.
try to recompile it with

cc -march=core2 -mtune=generic -O2 -pipe -fPIC -O3 -Wall -Iinclude -DUSE_SYS_DYN_MEM -DCAPSTONE_HAS_ARM -DCAPSTONE_HAS_ARM64 -DCAPSTONE_HAS_MIPS -DCAPSTONE_HAS_POWERPC -DCAPSTONE_HAS_X86 -fPIC -O3 -Wall -I../include -L.. -Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu -shared -Wl,-soname,libcapstone.so.2 test.o -O3 -Wall -lcapstone -o test

ldd output:

    linux-vdso.so.1 (0x00000342a0b84000)
    libc.so.6 => /lib64/libc.so.6 (0x00000342a05a1000)
    /lib64/ld-linux-x86-64.so.2 (0x00000342a0b85000)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/92#issuecomment-43042415
.

from capstone.

yeap, seems fixed
ps. He introduced a new variable $(LIBNAME)_LDFLAGS. That would help not to touch the main LDFLAGS variable.

from capstone.

merged the fix in "gentoo" into "next", thanks.

On Wed, May 14, 2014 at 3:35 PM, Anton Bolshakov
[email protected]:

Closed #92 #92.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/92#event-120899381
.

from capstone.