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.

Sign up for GitHub

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

Jump to bottom

ASSERT alloc.c:932 pt_parent!=NULL (callback stack off) with AppInit #243

Closed
derekbruening opened this issue Nov 27, 2014 · 6 comments
Closed

ASSERT alloc.c:932 pt_parent!=NULL (callback stack off) with AppInit #243

derekbruening opened this issue Nov 27, 2014 · 6 comments
Labels
Migrated Priority-Medium Status-CannotReproduce

Comments

@derekbruening
Copy link
Contributor

From [email protected] on December 14, 2009 15:26:09

I have a very strange situation on my windows laptop (Windows XP) with DrMemory.

  1. I've built base_unittests.exe from Chromium ( http://dev.chromium.org/developers/how- tos/build-instructions-windows)
  2. I've downloaded http://dynamorio.org/download/DrMemory-Windows-1.0.8-1.zip 3. I've run "drmemory -- base_unittests.exe" and that reported some warnings
  3. Next I run base_unittests.exe WITHOUT drmemory and I get a message box saying
    ASSERT FAILURE: E:/derek/dr/tot/internal/clients/drmemory/common/alloc.c:932
    pt_parent!=NULL (callback stack off)
  4. I rename base_unittests.exe to z.exe and that binary runs fine
  5. I rename it back -- it asserts.
  6. I reboot the machine but the problem remains

I am puzzled!!!

Does drmemory put anything into the system?

Original issue: http://code.google.com/p/dynamorio/issues/detail?id=243
@derekbruening
Copy link
Contributor Author

From [email protected] on December 14, 2009 17:11:47

The registry is used for DynamoRIO configuration on Windows (xref future plans to
make that optional for local, non-privileged usage of DR) but what you're describing
is not supposed to happen. Can you paste in the contents of this reg key:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs

@derekbruening
Copy link
Contributor Author

From [email protected] on December 14, 2009 17:17:47

Weird.
This reg key does indeed contain c:/drmemory/dynamorio\lib32\drpreinject.dll in the
first position.
When I remove it, everything works as expected...

@derekbruening
Copy link
Contributor Author

From [email protected] on December 14, 2009 17:31:52

So the key has other entries? Can you paste the contents (feel free to replace
alphanum for privacy if desired: the key parts are the comma delimiters)? Is the
problem reproducible? What if the key starts out blank (save and then restore
afterward of course)?

@derekbruening
Copy link
Contributor Author

From [email protected] on December 14, 2009 17:39:20

c:/drmemory/dynamorio\lib32\drpreinject.dll,C:\PROGRA1\xxx\xxx4\xxx.DLL,C:\PROGRA1\S
ophos\SOPHOS1\SOPHOS~1.DLL

blank in the beginning does not seem to change anything

@derekbruening
Copy link
Contributor Author

From [email protected] on October 25, 2011 19:53:07

We use config files now on all platforms, correct? The registry key support is still in there, though, right? So perhaps this issue could be re-titled "when using registry, drmemory leaves behind drpreinject.dll in registry for app exe" or something.

@derekbruening
Copy link
Contributor Author

From [email protected] on October 25, 2011 21:03:08

summary:

the whole config system has changed completely. seems reasonable to close this.

Summary: ASSERT alloc.c:932 pt_parent!=NULL (callback stack off) with AppInit
Status: CannotReproduce

derekbruening added a commit that referenced this issue Jul 5, 2023
@derekbruening
i#5383 mac a64, part 6: Get OSX-labeled tests to succeed
5537d2c 
8 of the 13 tests on Mac AArch64 labeled "OSX" fail prior to this PR.
Here we fix the following:

+ Syscall success is indicated by the carry flag just like x86 Mac
+ Handle sigreturn with its extra parameters just like x86 Mac
+ Fix signal handler parameters
+ Fix stolen register support in signal contexts
+ Use MAP_JIT and pthread_jit_write_protect_np for +rwx gencode in tests
+ Use DYLD_LIBRARY_PATH on Mac in tests

Now all 13 tests pass:
---------------------------------------------------------------------------------------
ctest -j 5 -L OSX
 1/13 Test  #13: code_api|common.fib ................................  Passed  0.59 sec
 2/13 Test #243: code_api|libutil.frontend_test .....................  Passed  0.63 sec
 3/13 Test #231: code_api|api.ir ....................................  Passed  0.67 sec
 4/13 Test   #9: code_api|linux.sigaction.native ....................  Passed  0.25 sec
 5/13 Test  #31: code_api|linux.signal0000 ..........................  Passed  0.10 sec
 6/13 Test #240: code_api|api.ir-static .............................  Passed  0.34 sec
 7/13 Test #241: code_api|api.drdecode ..............................  Passed  0.38 sec
 8/13 Test #245: code_api|api.dis-a64 ...............................  Passed  1.15 sec
 9/13 Test #264: no_code_api,no_intercept_all_signals|linux.sigaction  Passed  0.08 sec
10/13 Test  #33: code_api|linux.signal0010 ..........................  Passed  0.34 sec
11/13 Test  #35: code_api|linux.signal0100 ..........................  Passed  0.42 sec
12/13 Test  #37: code_api|linux.signal0110 ..........................  Passed  0.45 sec
13/13 Test   #7: samples_proj .......................................  Passed  1.89 sec
100% tests passed, 0 tests failed out of 13
---------------------------------------------------------------------------------------

Issue: #5383
@derekbruening derekbruening mentioned this issue Jul 5, 2023
Merged
github-merge-queue bot pushed a commit that referenced this issue Jul 7, 2023
@derekbruening
i#5383 mac a64, part 6: Get OSX-labeled tests to succeed (#6186)
85f1376 
8 of the 13 tests on Mac AArch64 labeled "OSX" fail prior to this PR.
Here we fix the following:

+ Syscall success is indicated by the carry flag just like x86 Mac
+ Handle sigreturn with its extra parameters just like x86 Mac
+ Fix signal handler parameters
+ Fix stolen register support in signal contexts
+ Use MAP_JIT and pthread_jit_write_protect_np for +rwx gencode in tests
+ Use DYLD_LIBRARY_PATH on Mac in tests

Now all 13 tests pass:
```
---------------------------------------------------------------------------------------
$ ctest -j 5 -L OSX
 1/13 Test  #13: code_api|common.fib ................................  Passed  0.59 sec
 2/13 Test #243: code_api|libutil.frontend_test .....................  Passed  0.63 sec
 3/13 Test #231: code_api|api.ir ....................................  Passed  0.67 sec
 4/13 Test   #9: code_api|linux.sigaction.native ....................  Passed  0.25 sec
 5/13 Test  #31: code_api|linux.signal0000 ..........................  Passed  0.10 sec
 6/13 Test #240: code_api|api.ir-static .............................  Passed  0.34 sec
 7/13 Test #241: code_api|api.drdecode ..............................  Passed  0.38 sec
 8/13 Test #245: code_api|api.dis-a64 ...............................  Passed  1.15 sec
 9/13 Test #264: no_code_api,no_intercept_all_signals|linux.sigaction  Passed  0.08 sec
10/13 Test  #33: code_api|linux.signal0010 ..........................  Passed  0.34 sec
11/13 Test  #35: code_api|linux.signal0100 ..........................  Passed  0.42 sec
12/13 Test  #37: code_api|linux.signal0110 ..........................  Passed  0.45 sec
13/13 Test   #7: samples_proj .......................................  Passed  1.89 sec
100% tests passed, 0 tests failed out of 13
---------------------------------------------------------------------------------------
```
Issue: #5383
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Migrated Priority-Medium Status-CannotReproduce
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@derekbruening