Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

stl_test not working properly on Linux? #534

Closed
derekbruening opened this issue Nov 28, 2014 · 22 comments
Closed

stl_test not working properly on Linux? #534

derekbruening opened this issue Nov 28, 2014 · 22 comments

Comments

@derekbruening
Copy link
Contributor

From timurrrr@google.com on August 10, 2011 10:32:50

This is Ubuntu Lucid x64

$ cat hello.c
#include <stdio.h>

int main(void) {
printf("Hello, world!\n");
return 0;
}
$ gcc -g -m32 hello.c -o hello
$ cd dynamorio
$ mkdir debug && cd debug
$ ld --version
GNU ld (GNU Binutils for Ubuntu) 2.20.1-system.20100303
$ CXXFLAGS=-m32 CFLAGS=-m32 cmake -DCMAKE_BUILD_TYPE=Debug .. && make -j10
...
$ ./bin32/drrun -client ./api/samples/bin/libbbcount.so 0 "" ~/sandbox/hello
Client bbcount is running
Hello
Instrumentation results:
1809 basic block executions
113 basic blocks needed flag saving
396 basic blocks did not

$ ./bin32/drrun -client ./api/samples/bin/libstl_test.so 0 "" ~/sandbox/hello
Segmentation fault <----- !!!!!!!!!

Original issue: http://code.google.com/p/dynamorio/issues/detail?id=534

@derekbruening
Copy link
Contributor Author

From timurrrr@google.com on August 10, 2011 07:33:15

I'm not very familiar with DR on Linux - am I right that running libXXX.so.debug is wrong?
Or is it DR that is wrong?

$ ./bin32/drrun -client ./api/samples/bin/libbbcount.so.debug 0 "" ~/sandbox/hello
<Application hello (5374). Client library targets an incompatible API version and should be re-compiled.>
Hello
$ ./bin32/drrun -client ./api/samples/bin/libstl_test.so.debug 0 "" ~/sandbox/hello
<Application hello (5224). Client library targets an incompatible API version and should be re-compiled.>
Hello

@derekbruening
Copy link
Contributor Author

From qin.zhao@gmail.com on August 10, 2011 07:36:04

I believe .debug is the file storing the debug symbols.

@derekbruening
Copy link
Contributor Author

From timurrrr@google.com on August 10, 2011 07:37:43

OK then why doesn't it call me crazy right away? :)

@derekbruening
Copy link
Contributor Author

From timurrrr@google.com on August 10, 2011 07:44:31

Same result on this simple test:
$ cat api/samples/emptycpp.cpp
#include "dr_api.h"
#include
using namespace std;

void event_exit() {}

DR_EXPORT void dr_init(client_id_t id) {
dr_register_exit_event(event_exit);
}

@derekbruening
Copy link
Contributor Author

From timurrrr@google.com on August 10, 2011 07:45:53

FTR, this is all happening on r925

@derekbruening
Copy link
Contributor Author

From timurrrr@google.com on August 10, 2011 07:53:43

oops, looks like "-DCMAKE_BUILD_TYPE=Debug" is no-op for DR.

However, I get the same segfault when building with -DDEBUG=ON

@derekbruening
Copy link
Contributor Author

From qin.zhao@gmail.com on August 10, 2011 07:57:32

.debug file itself is also a valid shared library file with much more debug information.

@derekbruening
Copy link
Contributor Author

From timurrrr@google.com on August 10, 2011 08:11:33

libstl_test.so passes when I remove all cout/cin/iostream lines from stl_test.cpp

@derekbruening
Copy link
Contributor Author

From bruen...@google.com on August 10, 2011 08:21:14

for future linux bug reports, what we need is info on the crash, and whether it works w/o private loader

this does work with -no_private_loader

the crash involves private loader TLS:

(gdb) bt
#0 get_gconv_fcts (c=128) at ./wcsmbsload.h:72
#1 __btowc (c=128) at btowc.c:49
#2 0xf7103fa0 in btowc (this=0xf713cde0) at /usr/include/wchar.h:388
#3 std::ctype<wchar_t>::_M_initialize_ctype (this=0xf713cde0) at ctype_members.cc:290
#4 0xf709e345 in std::ctype<wchar_t>::ctype (this=0xf713cde0, __refs=1) at ../../../../../src/libstdc++-v3/src/ctype.cc:110
#5 0xf70a67c6 in std::locale::_Impl::_Impl (this=0xf713d65c, __refs=2) at ../../../../../src/libstdc++-v3/src/locale_init.cc:411
#6 0xf70a70ad in std::locale::_S_initialize_once () at ../../../../../src/libstdc++-v3/src/locale_init.cc:251
#7 0xf70a711d in std::locale::_S_initialize () at ../../../../../src/libstdc++-v3/src/locale_init.cc:263
#8 0xf70a71a8 in std::locale::locale (this=0xf713c27c) at ../../../../../src/libstdc++-v3/src/locale_init.cc:210
#9 0xf70a2bd5 in basic_streambuf (this=0xf73c82b4)
at /build/buildd/gcc-4.4-4.4.3/build/x86_64-linux-gnu/32/libstdc++-v3/include/streambuf:442
#10 stdio_sync_filebuf (this=0xf73c82b4)
at /build/buildd/gcc-4.4-4.4.3/build/x86_64-linux-gnu/32/libstdc++-v3/include/ext/stdio_sync_filebuf.h:68
#11 std::ios_base::Init::Init (this=0xf73c82b4) at ../../../../../src/libstdc++-v3/src/ios_init.cc:85
#12 0xf73c315d in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at /usr/include/c++/4.4/iostream:72
#13 0xf73c319f in global constructors keyed to stl_test.cpp(void) () at /home/bruening/dr/git/src/api/samples/stl_test.cpp:168
#14 0xf73c549d in __do_global_ctors_aux ()
#15 0xf73c2120 in ?? ()
#16 0xf764c04f in privload_call_lib_func (func=0xf73c20f4) at /home/bruening/dr/git/src/core/linux/loader.c:704
#17 0xf764b855 in privload_call_entry (privmod=0x20ecb048, reason=1) at /home/bruening/dr/git/src/core/linux/loader.c:493
#18 0xf764bfab in privload_call_modules_entry (mod=0x20ecb048, reason=1) at /home/bruening/dr/git/src/core/linux/loader.c:677
#19 0xf764abed in os_loader_thread_init_prologue (dcontext=0x20eeb4c0) at /home/bruening/dr/git/src/core/linux/loader.c:174
#20 0xf759a1bb in loader_thread_init (dcontext=0x20eeb4c0) at /home/bruening/dr/git/src/core/loader_shared.c:169
#21 0xf744b75f in dynamo_thread_init (dstack_in=0x0, mc=0x0, client_thread=false) at /home/bruening/dr/git/src/core/dynamo.c:2114
#22 0xf744910e in dynamorio_app_init () at /home/bruening/dr/git/src/core/dynamo.c:570
#23 0xf73d67c7 in _init () at /home/bruening/dr/git/src/core/linux/preload.c:186

(gdb) disas __btowc
Dump of assembler code for function __btowc:
0xf6e19090 <+0>: push %ebp
0xf6e19091 <+1>: mov %esp,%ebp
0xf6e19093 <+3>: sub $0x68,%esp
0xf6e19096 <+6>: mov %esi,-0x8(%ebp)
0xf6e19099 <+9>: mov 0x8(%ebp),%esi
0xf6e1909c <+12>: mov %ebx,-0xc(%ebp)
0xf6e1909f <+15>: call 0xf6db1a0f <__i686.get_pc_thunk.bx>
0xf6e190a4 <+20>: add $0xd7f50,%ebx
0xf6e190aa <+26>: mov %edi,-0x4(%ebp)
0xf6e190ad <+29>: lea 0x80(%esi),%edx
0xf6e190b3 <+35>: mov %esi,%eax
0xf6e190b5 <+37>: cmp $0x17f,%edx
0xf6e190bb <+43>: ja 0xf6e19130 <__btowc+160>
0xf6e190bd <+45>: cmp $0xffffffff,%esi
0xf6e190c0 <+48>: je 0xf6e19130 <__btowc+160>
0xf6e190c2 <+50>: test $0xffffff80,%esi
0xf6e190c8 <+56>: je 0xf6e1911e <__btowc+142>
0xf6e190ca <+58>: mov -0x58(%ebx),%eax
0xf6e190d0 <+64>: mov %gs:(%eax),%eax
0xf6e190d3 <+67>: mov (%eax),%edi
=> 0xf6e190d5 <+69>: mov 0x14(%edi),%edx

(gdb) info reg
eax 0xf6ebc2a0 -152321376
ecx 0xf6ebc2a0 -152321376
edx 0x100 256
ebx 0xf6ef0ff4 -152104972
esp 0xff819140 0xff819140
ebp 0xff8191a8 0xff8191a8
esi 0x80 128
edi 0x0 0
eip 0xf6e190d5 0xf6e190d5 <__btowc+69>

Status: Accepted
Owner: qin.zhao@gmail.com
Labels: -Priority-Medium Priority-High

@derekbruening
Copy link
Contributor Author

From qin.zhao@gmail.com on August 25, 2011 13:00:35

Status: Fixed

@derekbruening
Copy link
Contributor Author

From timurrrr@google.com on August 26, 2011 03:02:09

Better now ( r951 ) but still seg.faults on exit:

$ ./bin32/drrun -client ./api/samples/bin/libstl_test.so 0 "" ~/sandbox/hello
Start...
input a tls value
4
Set tls var to 4
testing vector...01234
testing list...01234
testing map...01234
SUCCESS
Hello
value of tls_var on exit: 4
Segmentation fault


The emptycpp.cpp client is OK now

Status: Started

@derekbruening
Copy link
Contributor Author

From qin.zhao@gmail.com on August 26, 2011 08:25:36

Is it possible to provide more information about either the seg fault context, or how I can reproduce the problem?

@derekbruening
Copy link
Contributor Author

From timurrrr@google.com on August 26, 2011 08:27:45

or how I can reproduce the problem?
Look at the c#0

@derekbruening
Copy link
Contributor Author

From qin.zhao@gmail.com on August 26, 2011 08:33:26

../exports/bin32/drrun -debug -ops "-loglevel 0 -msgbox_mask 0x0" -client ../exports/samples/bin32/libstl_test.so 0 "" ../../test/hello-32b
<In GDB, use add-symbol-file /home/zhaoqin/Workspace/DynamoRIO/dynamorio/exports/samples/bin32/libstl_test.so 0xf74846d0 to add symbol information>
<Starting application hello-32b (20601)>
<In GDB, use add-symbol-file /usr/lib32/libstdc++.so.6 0xf716d2e0 to add symbol information>
<In GDB, use add-symbol-file /lib32/libm.so.6 0xf72b04b0 to add symbol information>
<In GDB, use add-symbol-file /lib/ld-linux.so.2 0xf728f830 to add symbol information>
<In GDB, use add-symbol-file /lib32/libc.so.6 0xf6e8bac0 to add symbol information>
<In GDB, use add-symbol-file /usr/lib32/libgcc_s.so.1 0xf7274f50 to add symbol information>
<Initial options = -client_lib '/home/zhaoqin/Workspace/DynamoRIO/dynamorio/exports/samples/bin32/libstl_test.so;0;' -code_api -stack_size 20K -max_elide_jmp 0 -max_elide_call 0 -no_inline_ignored_syscalls -no_native_exec -no_indcall2direct >
Start...
input a tls value
4
Set tls var to 4
testing vector...01234
testing list...01234
testing map...01234
SUCCESS
Hello, world!
<Stopping application hello-32b (20601)>
value of tls_var on exit: 4
Exit...

It worked on my machine. It looks the segfault happens before the last Exit is printed, so something is wrong while libraries calling their fini functions

@derekbruening
Copy link
Contributor Author

From timurrrr@google.com on August 26, 2011 08:45:10

Hm, looks like I have a release build (?!)
$ ./bin32/drrun -debug -ops "-loglevel 0 -msgbox_mask 0x0" -client ./api/samples/bin/libstl_test.so 0 "" ~/sandbox/hello
ERROR - libdynamorio.so not found in .../dynamorio/b/lib32/debug
usage: ./bin32/drrun [-v] [-debug] [-32] [-64] [-reg ] [-unreg <executable] [-norun] [-dr_home ] [-ops <dr_options>]* [-logdir ] [-client ""]* [args ...]

@derekbruening
Copy link
Contributor Author

From timurrrr@google.com on August 26, 2011 08:47:24

Oh, right: -DDEBUG=ON, not -DCMAKE_BUILD_TYPE=Debug
In debug it passes OK and finishes on "Exit..."

Can you try a release build?

@derekbruening
Copy link
Contributor Author

From qin.zhao@gmail.com on August 26, 2011 09:04:14

Yes, the release build cause the problem. I will look into it.

@derekbruening
Copy link
Contributor Author

From qin.zhao@gmail.com on September 28, 2011 21:15:19

Can you check if it works in the TOT revision.

@derekbruening
Copy link
Contributor Author

From timurrrr@google.com on September 30, 2011 04:43:19

I think it works for me now.
What revisions fixed this problem?

@derekbruening
Copy link
Contributor Author

From qin.zhao@gmail.com on September 30, 2011 08:19:29

closed by r1003 , which fixes the issue i555, client system call using sysenter.

Status: Fixed

@derekbruening
Copy link
Contributor Author

From timurrrr@google.com on September 30, 2011 08:46:28

Just curious: did I help you find a sysenter bug or is it just a coincidence?

@derekbruening
Copy link
Contributor Author

From qin.zhao@gmail.com on September 30, 2011 08:53:08

It started with this issue, and I tried to reproduce the problem without using c++ library, and find the issue #555 . I am still not sure if this issue is completely resolved in all platforms.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant