search

DynamoRIO / drmemory

Memory Debugger for Windows, Linux, Mac, and Android
Other
2.37k stars 257 forks source link

ASSERT FAILURE (thread 860): ..\common\symcache.c:229: (bsz) > (sofar) (buffer size miscalculation) #692

Open derekbruening opened 9 years ago

derekbruening commented 9 years ago

From rnk@google.com on November 18, 2011 13:34:41

This happens during unit_tests.exe shutdown when run without -quiet and -no_results_to_stderr as on the bot here: http://chromegw.corp.google.com/i/chromium.fyi/builders/Windows%20Tests%20%28DrMemory%20Win%207%29/builds/1342/steps/memory%20test%3A%20unit/logs/stdio

Original issue: http://code.google.com/p/drmemory/issues/detail?id=692

derekbruening commented 9 years ago

From rnk@google.com on November 18, 2011 11:28:37

I'm going to buffer the output and write it out to the file as we go.

Status: Started
Owner: rnk@google.com

derekbruening commented 9 years ago

From rnk@google.com on November 18, 2011 11:32:18

BTW, the same issue appears in the third unit_tests.exe shard: http://build.chromium.org/p/chromium.fyi/builders/Windows%20Tests%20%28DrMemory%20Win%207%29/builds/1342/steps/memory%20test%3A%20unit_2/logs/stdio

derekbruening commented 9 years ago

From timurrrr@google.com on November 18, 2011 12:27:55

Baaah. Can you please update the regexp in drmemory_analyze.py to match this assertion?

Also [trollface], sounds like the problem was with dealing with strings in C and wouldn't happen in C++?

derekbruening commented 9 years ago

From rnk@google.com on November 18, 2011 12:33:25

Yes, and this is the third/fourth time it's happened since I've been on the project. =/

derekbruening commented 9 years ago

From bruen...@google.com on November 18, 2011 12:35:11

nothing to do w/ C vs C++, it was me being too lazy to change DR to support file renaming b/c the first iteration of symcaches were very small and it was not worth the complexity there

did you verify there's not something else going on causing problems? is this simply capacity w/ regular entries (mostly post-call I assume)?

derekbruening commented 9 years ago

From rnk@google.com on November 21, 2011 11:00:02

I just double-checked, and the symcache file for unit_tests.exe was 128k. The entries were more or less all post call addresses. The bot cycled and blew away the logs dir before I got a change to look for duplicate lines.

derekbruening commented 9 years ago

From timurrrr@google.com on November 22, 2011 04:16:12

The bot cycled and blew away the logs dir before I got a change to look for duplicate lines. One more hint: run with --keep_logs from build\src and it won't be affected by the "usual" bot runs.

The bot runs the scripts from build\ so DrMemory.logs shouldn't conflict. Probably you don't need to override the --keep_logs default in the runner script (noticed it in svn diff on the bot)

Attached is the "DrMemory.logs" directory zipped after a full unit_tests run on the bot, ended with:

Dr.M Details: ...\build\src\DrMemory.logs/DrMemory-unit_tests.exe.2076.000/results.txt Dr.M ASSERT FAILURE (thread 3244): ..\common\symcache.c:229: (bsz) > (sofar) (buffer size miscalculation) 03:24:38 common.py [INFO] process ended, did not time out 03:24:38 common.py [INFO] flushing stdout 03:24:38 common.py [INFO] collecting result code 03:24:38 common.py [ERROR] ...\drmemory.exe exited with non-zero result code -1

Attachment: DrMemory.logs.zip