From [email protected] on August 13, 2010 04:24:29

Also I saw the following assert on r33 :
[ RUN ] MessageLoopTest.RecursiveDenial2
:::Dr.Memory::: ASSERT FAILURE (thread 3208): drmemory\syscall.c:220: shadow_get_byte(pc + 0) != SHADOW_UNADDRESSABLE ()

from drmemory.

From [email protected] on August 16, 2010 02:00:29

This assert has fired on winthreads test on r33 .

from drmemory.

From [email protected] on August 19, 2010 20:34:58

the syscall.c:220 assert was fixed in r34 for the title assert, I can repro (w/ issue #26 fixed: sorry still waiting on review for that one) in base_unittests and what I see is that it's kernel32!FlsGetData that's doing the access, and it's due to the app flsdata ptr in TEB being set to the private library version on a reset.

Owner: derek.bruening

from drmemory.

From [email protected] on August 20, 2010 16:03:55

this is a private library isolation issue.
fixed in DynamoRIO r411 .
however I recommend going to r413 as some other related issues were also fixed.

Status: Fixed

from drmemory.

From [email protected] on August 20, 2010 23:16:19

Great, thank you!
Will try that on Monday

from drmemory.

From [email protected] on August 23, 2010 05:48:31

All MessageLoopTests pass under r38 / r414 .

Status: Verified

from drmemory.

From [email protected] on September 25, 2010 08:04:14

Re-appeared in r57 / r434 (or was there all the time?): http://build.chromium.org/buildbot/waterfall.fyi/builders/Windows%20Tests%20(DrMemory)/builds/2905/steps/memory%20test:%20net_2/logs/stdio ...
[----------] 2 tests from DNSSECChainVerifierTest
[ RUN ] DNSSECChainVerifierTest.TestChain
:::Dr.Memory::: ASSERT FAILURE (thread 9820): C:\drmemory-build\drmemory\drmemory\readwrite.c:2656: !dr_memory_is_dr_internal(addr) && !dr_memory_is_in_client(addr) (app is using tool's memory: please report this!)

Status: Accepted

from drmemory.

From [email protected] on September 25, 2010 08:09:01

That is net_unittests.
I'll try reproducing that on Monday

from drmemory.

From [email protected] on February 17, 2011 07:23:12

This happens to me locally on XP with r178 on Chromium's remoting_unittests.

Derek, can you try running that?
I used this command line in a Chromium checkout:
tools\valgrind\chrome_tests.bat -t remoting_unittests --tool drmemory --gtest_filter="ChromotingHostTest.Connect"
which is essentially the same as
drmemory.exe build\Debug\remoting_unittests.exe --gtest_filter="ChromotingHostTest.Connect"

from drmemory.

From [email protected] on February 17, 2011 08:32:51

Huh, looks like the repro is not stable enough again :(
Anyways, can you try running some Chromium tests like "remoting" or "net" in your local setup? Maybe you'll find some assertions as well.

from drmemory.

From [email protected] on February 25, 2011 10:43:42

is ChromotingHostTest.Connect a new test from the last few weeks? I'll sync and rebuild, but here's what I get:

C:\derek\chrome>c:\derek\exports_drmemory\bin\drmemory.exe -pause_at_assert -dr
c:/derek/exports -- ./remoting_unittests.exe --gtest_filter="ChromotingHostTest.
Connect"
:::Dr.Memory::: Dr. Memory version 1.4.193
:::Dr.Memory::: options are "-pause_at_assert -logdir c:\derek\exports_drmemory /drmemory/logs -resfile_out "
:::Dr.Memory::: log dir is c:\derek\exports_drmemory/drmemory/logs/DrMemory-remo
ting_unittests.exe.52956.000
Note: Google Test filter = ChromotingHostTest.Connect
[==========] Running 0 tests from 0 test cases.
[==========] 0 tests from 0 test cases ran. (78 ms total)
[ PASSED ] 0 tests.
:::Dr.Memory::: ERRORS FOUND:
:::Dr.Memory::: 0 unique, 0 total unaddressable access(es)
:::Dr.Memory::: 0 unique, 0 total uninitialized access(es)
:::Dr.Memory::: 0 unique, 0 total invalid heap argument(s)
:::Dr.Memory::: 0 unique, 0 total warning(s)
:::Dr.Memory::: 0 unique, 0 total, 0 byte(s) of leak(s)
:::Dr.Memory::: 0 unique, 0 total, 0 byte(s) of possible leak(s)
:::Dr.Memory::: ERRORS IGNORED:
:::Dr.Memory::: 0 suppressed error(s)
:::Dr.Memory::: 0 suppressed leak(s)
:::Dr.Memory::: 110 ignored assumed-innocuous system leak(s)
:::Dr.Memory::: 572 still-reachable allocation(s)
:::Dr.Memory::: (re-run with "-show_reachable" for details)
:::Dr.Memory::: 0 error(s) beyond -report_max
:::Dr.Memory::: 0 leak(s) beyond -report_leak_max
:::Dr.Memory::: Details: c:\derek\exports_drmemory/drmemory/logs/DrMemory-remoti
ng_unittests.exe.52956.000/results.:::Dr.Memory::: txt

C:\derek\chrome>c:\derek\exports_drmemory\bin\drmemory.exe -pause_at_assert -dr
c:/derek/exports -- ./remoting_unittests.exe --gtest_filter="ChromotingHost_"
:::Dr.Memory::: Dr. Memory version 1.4.193
:::Dr.Memory::: options are "-pause_at_assert -logdir c:\derek\exports_drmemory /drmemory/logs -resfile_out "
:::Dr.Memory::: log dir is c:\derek\exports_drmemory/drmemory/logs/DrMemory-remo
ting_unittests.exe.59752.000
Note: Google Test filter = ChromotingHost_
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from ChromotingHostContextTest
[ RUN ] ChromotingHostContextTest.StartAndStop
[ OK ] ChromotingHostContextTest.StartAndStop (1172 ms)
[----------] 1 test from ChromotingHostContextTest (1422 ms total)

[----------] Global test environment tear-down
[==========] 1 test from 1 test case ran. (1594 ms total)
[ PASSED ] 1 test.
:::Dr.Memory::: ERRORS FOUND:
:::Dr.Memory::: 0 unique, 0 total unaddressable access(es)
:::Dr.Memory::: 1 unique, 9 total uninitialized access(es)
:::Dr.Memory::: 0 unique, 0 total invalid heap argument(s)
:::Dr.Memory::: 0 unique, 0 total warning(s)
:::Dr.Memory::: 0 unique, 0 total, 0 byte(s) of leak(s)
:::Dr.Memory::: 0 unique, 0 total, 0 byte(s) of possible leak(s)
:::Dr.Memory::: ERRORS IGNORED:
:::Dr.Memory::: 0 suppressed error(s)
:::Dr.Memory::: 0 suppressed leak(s)
:::Dr.Memory::: 110 ignored assumed-innocuous system leak(s)
:::Dr.Memory::: 572 still-reachable allocation(s)
:::Dr.Memory::: (re-run with "-show_reachable" for details)
:::Dr.Memory::: 0 error(s) beyond -report_max
:::Dr.Memory::: 0 leak(s) beyond -report_leak_max
:::Dr.Memory::: Details: c:\derek\exports_drmemory/drmemory/logs/DrMemory-remoti
ng_unittests.exe.59752.000/results.:::Dr.Memory::: txt

from drmemory.

From [email protected] on February 25, 2011 11:53:28

I did a sync but I still don't see that test.

I can run the whole remoting_unittests on xp32sp3 and it runs to completion w/ mostly-known failures:

c:\derek\exports_drmemory\bin\drmemory.exe -pause_at_assert -dr c:/derek/exports -- ./remoting_unittests.exe --gtest_filter="-DecoderVp8Test.EncodeAndDecode"
...
[ PASSED ] 97 tests.
[ FAILED ] 7 tests, listed below:
[ FAILED ] JingleSessionTest.CreateAndDestoy
[ FAILED ] JingleSessionTest.RejectConnection
[ FAILED ] JingleSessionTest.Connect
[ FAILED ] JingleSessionTest.TestControlChannel
[ FAILED ] JingleSessionTest.TestVideoChannel
[ FAILED ] JingleSessionTest.TestEventChannel
[ FAILED ] JingleSessionTest.TestVideoRtpChannel

7 FAILED TESTS

from drmemory.

From [email protected] on February 28, 2011 12:35:44

Status: CannotReproduce

from drmemory.

From [email protected] on July 21, 2011 04:14:19

I can repro with r405 reliably on Win 7 when DrM'ing Chrome.exe
on the HTML page given at https://code.google.com/p/chromium/issues/detail?id=88213 (you should have access)
Can you try that as well?

I've attached with windbg:

kn

ChildEBP RetAddr

00 1b918708 7241345c ntdll!NtRaiseHardError+0x12
01 1b91874c 723fd00e dynamorio!nt_messagebox+0x7c [dynamorio\core\win32\ntdll.c @ 3294]
02 1b919794 1011b8ec dynamorio!dr_messagebox+0x8e [dynamorio\core\x86\instrument.c @ 3131]
03 1b9197a0 1011b931 drmemorylib!wait_for_user+0xc [common\utils.c @ 82]
04 1b9197ec 100e55ef drmemorylib!drmemory_abort+0x31 [common\utils.c @ 110]
05 1b9198d4 1001cb03 drmemorylib!check_unaddressable_exceptions+0xc1f [drmemory\alloc_drmem.c @ 1928]
06 1b919b98 100ea7ef drmemorylib!handle_mem_ref+0x1613 [drmemory\readwrite.c @ 2921]
07 1b919bf8 101281e5 drmemorylib!check_sysmem+0x3bf [drmemory\syscall.c @ 634]
08 1b919c30 1012f116 drmemorylib!handle_cwstring+0x165 [drmemory\syscall_windows.c @ 1387]
09 1b919c9c 1012f5ca drmemorylib!handle_wndclassexw_access+0x156 [drmemory\syscall_wingdi.c @ 1058]
0a 1b919cc4 101283f0 drmemorylib!wingdi_process_syscall_arg+0x9a [drmemory\syscall_wingdi.c @ 1404]
0b 1b919cec 10128222 drmemorylib!os_handle_syscall_arg_access+0x1c0 [drmemory\syscall_windows.c @ 1441]
0c 1b919d10 100ee25c drmemorylib!os_handle_pre_syscall_arg_access+0x22 [drmemory\syscall_windows.c @ 1450]
0d 1b919d80 100ec7ca drmemorylib!process_pre_syscall_reads_and_writes+0x38c [drmemory\syscall.c @ 836]
0e 1b919f3c 723fbe41 drmemorylib!event_pre_syscall+0x43a [drmemory\syscall.c @ 979]
0f 1b919f70 723aa141 dynamorio!instrument_pre_syscall+0xa1 [dynamorio\core\x86\instrument.c @ 1684]
10 1b919f98 723aae8c dynamorio!handle_system_call+0x71 [dynamorio\core\dispatch.c @ 1628]
11 1b919fbc 723aaf02 dynamorio!dispatch_enter_dynamorio+0x42c [dynamorio\core\dispatch.c @ 727]
12 1b8c8180 00000000 dynamorio!dispatch+0x12 [dynamorio\core\dispatch.c @ 148]

you can find the .dmp + DLL + pdb files in ~timurrrr/dr-sandbox/issues/i25.zip

Do you need any extra info?

Summary: ASSERT: drmemory\alloc_drmem.c:1928: !dr_memory_is_dr_internal(addr) && !dr_memory_is_in_client(addr) (app is using tool's memory: please report this!)
Status: New

from drmemory.

From [email protected] on July 22, 2011 08:05:56

note that this particular assert can fire for any number of underlying causes: any syscall param handling bug could potentially hit it, so best to open a new issue rather than re-open this one.

almost certainly dup of issue #505 , fixed in r408

Status: Duplicate
Mergedinto: 505

from drmemory.

From [email protected] on July 22, 2011 08:19:44

Agree; looking at the issue #505 I'm pretty sure it was the cause.

from drmemory.