gdbprofiler icon indicating copy to clipboard operation
gdbprofiler copied to clipboard

stack-list-frames error result: (Gdbmi_types.OpError ("No registers.", None))

Open aantron opened this issue 9 years ago • 11 comments

I get this result when running measure.ml to completion:

ocamlfind opt -g -linkpkg -package unix -package markup measure.ml && ./a.out React-1774 & sleep 1 && rmp -p `pidof a.out` --cpuprofile react.cpuprofile
[1] 20180
Press enter to stop
cpu:  126.0 ms
wall: 128.1 ms
[1]  + 20180 done       ./a.out React-1774
Fatal error: exception Failure("stack-list-frames error result: (Gdbmi_types.OpError (\"No registers.\", None))")
Raised at file "src/core/lwt.ml", line 805, characters 16-23
Called from file "src/unix/lwt_main.ml", line 34, characters 8-18
Called from file "cli/rmp.ml", line 158, characters 4-61

This is on an OS X system using GNU gdb 7.9.1 from MacPorts. I am sure that this is using MacPorts gdb because I had to patch Gdb.launch to start ggdb instead of trying gdb, which could be its own issue.

If I "press enter," I get this instead:

Fatal error: exception Failure("Empty records")

May look into this in a few days. Would be nice to get rmp running :)

aantron avatar Dec 06 '16 00:12 aantron

I found the same thing. It's also hard to get enter to take effect. (It does occasionally, but often hitting enter doesn't work either).

jordwalke avatar Dec 22 '16 06:12 jordwalke

It seems I am able to start my program like this:

(./Test.native > /dev/null&) && \
  ~/github/rmp/_build/ocamlfind/bin/rmp -p `pgrep Test.native` \
  --cpuprofile Test.cpuprofile \
  --callgrind Test.callgrind

I can then verify that for a brief time, my program is running at the same time that rmp is supposed to be profiling it: Notice that the pid matches.

pid: 89956  ./Test.native
pid: 89958  /Users/me/github/rmp/_build/ocamlfind/bin/rmp -p 89956 --cpuprofile Test.cpuprofile --callgrind Test.callgrind

But then later, I can see that the process 89956 dies, and yet rmp is still left profiling a process that has ran to completion successfully (I think?) However, at this point, hitting enter does not stop rmp. I think that if I hit enter before the Test.native program completes, then I get the same error that @aantron showed. But if I wait too long, not even enter has any effect.

Here's the stack trace from that error that @aantron showed:

Fatal error: exception Failure("Empty records")
Raised at file "src/core/lwt.ml", line 789, characters 22-23
Called from file "src/unix/lwt_main.ml", line 34, characters 8-18

jordwalke avatar Dec 22 '16 06:12 jordwalke

Debugging the log statements (I have to make log print to stdout because otherwise it never writes to the log since I'm forced to kill the program (it doesn't gracefully write to the log on crash apparently)).


continuing ...

continued

sampling gdb

Sending sigint

timeout, retrying

Sending sigint

timeout, retrying

Sending sigint

timeout, retrying

jordwalke avatar Dec 22 '16 06:12 jordwalke

A more detailed view (printing out the gdb process to confirm it's not zero or something):

starting

launched


attached 98384

continuing ...

continued

sampling gdb

Sending sigint


querying gdb with pd: 98387
timeout, retrying

Sending sigint


querying gdb with pd: 98387
timeout, retrying

Sending sigint


querying gdb with pd: 98387
timeout, retrying

Sending sigint


querying gdb with pd: 98387
timeout, retrying

Sending sigint


querying gdb with pd: 98387
timeout, retrying

Sending sigint


querying gdb with pd: 98387
timeout, retrying

Sending sigint

jordwalke avatar Dec 22 '16 06:12 jordwalke

More information - even though gdb claims to be attached, the gdb process dies before the attached process dies.

jordwalke avatar Dec 22 '16 07:12 jordwalke

And even more information: Here's the log including the responses from gdb. You can see there's some error that's being swallowed unless you force the log to print to stdout:

starting


receive: =thread-group-added,id="i1"

receive: ~"GNU gdb (GDB) 7.12\n"

receive: ~"Copyright (C) 2016 Free Software Foundation, Inc.\n"

receive: ~"License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>\nThis is free software: you are free to change and redistribute it.\nThere is NO WARRANTY, to the extent permitted by law.  Type \"show copying\"\nand \"show warranty\" for details.\n"

receive: ~"This GDB was configured as \"x86_64-apple-darwin16.1.0\".\nType \"show configuration\" for configuration details."

receive: ~"\nFor bug reporting instructions, please see:\n"

receive: ~"<http://www.gnu.org/software/gdb/bugs/>.\n"

receive: ~"Find the GDB manual and other documentation resources online at:\n<http://www.gnu.org/software/gdb/documentation/>.\n"

receive: ~"For help, type \"help\".\n"

receive: ~"Type \"apropos word\" to search for commands related to \"word\".\n"

receive: (gdb) 
launched


send: attach 99244

receive: &"attach 99244\n"

receive: ~"Attaching to process 99244\n"

receive: =thread-group-started,id="i1",pid="99244"

receive: =thread-created,id="1",group-id="i1"

receive: ^done

receive: ~"Reading symbols from /Users/jwalke/github/ExampleProject/_build/src/Test.native..."

receive: ~"(no debugging symbols found)...done.\n"

receive: &"warning: unhandled dyld version (15)\n"

receive: ~"0x0000000106ca06cf in ?? ()\n"

receive: *stopped,frame={addr="0x0000000106ca06cf",func="??",args=[]},thread-id="1",stopped-threads="all"

receive: (gdb) 

attached 99244
STARTING LOOP
IN LOOP

continuing ...


send: continue

receive: &"continue\n"

receive: ~"Continuing.\n"

receive: ^running

receive: *running,thread-id="all"

receive: (gdb) 
continued

sampling gdb

Sending sigint


querying gdb with pd: 99290 

send: 

receive: ~"darwin-nat.c:1354: internal-error: void darwin_interrupt(struct target_ops *, ptid_t): Assertion `!inf->priv->no_ptrace' failed.\nA problem internal to GDB has been detected,\nfurther debugging may prove unreliable.\nQuit this debugging session? "

receive: ~"(y or n) [answered Y; input not from terminal]\n"

receive: &"\nThis is a bug, please report it."

receive: &"  For instructions, see:\n<http://www.gnu.org/software/gdb/bugs/>."

receive: &"\n\n"

receive: ~"darwin-nat.c:1354: internal-error: void darwin_interrupt(struct target_ops *, ptid_t): Assertion `!inf->priv->no_ptrace' failed.\nA problem internal to GDB has been detected,\nfurther debugging may prove unreliable.\nCreate a core file of GDB? "

receive: ~"(y or n) [answered Y; input not from terminal]\n"
timeout, retrying

Sending sigint


querying gdb with pd: 99290 

send: 
timeout, retrying

Sending sigint


querying gdb with pd: 99290 

send: 
timeout, retrying

Sending sigint


querying gdb with pd: 99290 

send: 
timeout, retrying

Sending sigint



jordwalke avatar Dec 22 '16 07:12 jordwalke

receive: ~"darwin-nat.c:1354: internal-error: void darwin_interrupt(struct target_ops *, ptid_t): Assertion `!inf->priv->no_ptrace' failed.\nA problem internal to GDB has been detected,\nfurther debugging may prove unreliable.\nQuit this debugging session? " receive: ~"(y or n) [answered Y; input not from terminal]\n" receive: &"\nThis is a bug, please report it." receive: &" For instructions, see:\nhttp://www.gnu.org/software/gdb/bugs/." receive: &"\n\n"

This looks pretty bad, can you check that gdb works at all on your machine, by running the following:

$ gdb
> attach 12345 # some ocaml program
> continue
CTRL-C

copy avatar Dec 27 '16 21:12 copy

I just tried and unfortunately, gdb seems to be quite broken on OSX. I'll update the readme accordingly.

I also installed llvm from brew in order to get lldb-mi (OSX ships with lldb but not with lldb-mi), and it doesn't work either, failing with Attach to process failed without any additional information. lldb works though, so there is a glimmer of hope.

If anybody gets either gdb or lldb-mi working, let me know.

copy avatar Jul 04 '17 22:07 copy

Same problem on Linux Mint:

Fatal error: exception Failure("stack-list-frames error result: (Gdbmi_types.OpError (\"No registers.\", None))")
Raised at file "src/core/lwt.ml", line 2719, characters 24-25
Called from file "src/unix/lwt_main.ml", line 33, characters 8-18

cpitclaudel avatar Jul 30 '17 14:07 cpitclaudel

For me the problem happens if I the profiled program exits before gdbprofiler (that is, if I don't press enter fast enough)

cpitclaudel avatar Jul 30 '17 16:07 cpitclaudel

@cpitclaudel What's the output of gdb --version? If possible, could you let me know which program you're profiling?

copy avatar Jul 31 '17 04:07 copy