Open MarteinB opened 9 years ago
Please provide more information:
The fault is here:
dynamorio!instr_encode_arch+0x3f3 [d:\drmemory_package\dynamorio\core\arch\x86\encode.c @ 2557]:
7108cf83 8813 mov byte ptr [ebx],dl
That's the 1st write:
/* first opcode byte */
*field_ptr = (byte)((info->opcode & 0x00ff0000) >> 16);
So it's trying to encode to address 0.
Hi Derek,
Thanks for your support. The answers to your questions are:
Is this on startup of the app, after hours of running the app, only on some runs, on every run, ...? It is during startup of the App, but it gets quite far until crash occurs.
Is this a regression where older DrMem versions worked and 1.9.0-RC1 does not? I have also tried 1.8 and it crashes also during startup of the App.
Do other apps on this same machine work fine under DrMem? Yes
What happens with each runtime option listed under "Narrowing Down the Source of the Problem" at https://github.com/DynamoRIO/drmemory/wiki/Debugging?
Without any options:
[cid:image002.png@01D0E631.9A482630]
With –no_count_leaks:
[cid:image001.png@01D0E62F.A86AD750]
With the following options DrMemory runs OK: -light -leaks_only -leaks_only -no_count_leaks -leaks_only -no_count_leaks -no_track_allocs
I hope this will help to narrow things down a bit.
Best regards, Martein
From: derekbruening [mailto:notifications@github.com] Sent: Wednesday, September 02, 2015 4:38 PM To: DynamoRIO/drmemory Cc: Bakker, Martein Subject: Re: [drmemory] Dr. Memory internal crash at PC 0x702ccf83 (#1765)
Please provide more information:
The fault is here:
dynamorio!instr_encode_arch+0x3f3 [d:\drmemory_package\dynamorio\core\arch\x86\encode.c @ 2557]:
7108cf83 8813 mov byte ptr [ebx],dl
That's the 1st write:
/* first opcode byte */
*field_ptr = (byte)((info->opcode & 0x00ff0000) >> 16);
So it's trying to encode to address 0.
— Reply to this email directly or view it on GitHubhttps://github.com/DynamoRIO/drmemory/issues/1765#issuecomment-137105936.
Unfortunately the mini-callstack in the crash report is incomplete, leaving too little information to figure out the problem. Would it be possible to obtain a minimally reproducing application so that we can try to reproduce?
Alternatively, logs might be sufficient, though it's hard to say. To obtain logs, run with something like:
-debug -verbose 3 -dr_debug -dr_ops "-loglevel 3"
If that is just too slow, s/3/2/. The resulting logs are in drmemory/logs/ -- maybe just zip the whole thing, or pull out the DrMemory-
Hi Derek,
I tried the verbose mode, but it takes “forever” and the application under test is not yet visible when DrMemory gets in trouble in different ways:
[cid:image001.png@01D0EBBA.4996FA20]
[cid:image002.png@01D0EBBA.C05E14E0]
I have asked permission to submit to you the application (MSI installer + .dbg files). So you can install that in VM-ware and reproduce the crash there. Once the permission is there, I will upload the files to you. Is there a location that I can use for the upload? It will be quite big. (a few hundred MB)
Best regards, Martein
From: derekbruening [mailto:notifications@github.com] Sent: Wednesday, September 09, 2015 7:26 PM To: DynamoRIO/drmemory Cc: Bakker, Martein Subject: Re: [drmemory] Dr. Memory internal crash at PC 0x702ccf83 (#1765)
Alternatively, logs might be sufficient, though it's hard to say. To obtain logs, run with something like:
-debug -verbose 3 -dr_debug -dr_ops "-loglevel 3"
If that is just too slow, s/3/2/. The resulting logs are in drmemory/logs/ -- maybe just zip the whole thing, or pull out the DrMemory-.* and the dynamorio/.* dirs.
— Reply to this email directly or view it on GitHubhttps://github.com/DynamoRIO/drmemory/issues/1765#issuecomment-138983094.