
Hello, I have a program which uses some code in a package, and I would like to be able to find out the source of an error which is occuring inside that package. Can I use the ghci-debugger to do this? If I try to set a breakpoint inside the package, it says: "cannot set breakpoint on Vector.Sparse.Wrappers.vmergeOp: module Vector.Sparse.Wrappers is not interpreted" But this page: http://www.haskell.org/ghc/dist/current/docs/users_guide/ghci-debugger.html has no use of the word "package", so I assume that reading that (long) document won't ansnwer my question... Thank you, Frederik -- http://ofb.net/~frederik/

Am Sonntag, 24. Februar 2008 02:18 schrieb Frederik Eaton:
Hello,
I have a program which uses some code in a package, and I would like to be able to find out the source of an error which is occuring inside that package. Can I use the ghci-debugger to do this? If I try to set a breakpoint inside the package, it says:
"cannot set breakpoint on Vector.Sparse.Wrappers.vmergeOp: module Vector.Sparse.Wrappers is not interpreted"
But this page:
http://www.haskell.org/ghc/dist/current/docs/users_guide/ghci-debugger.html
has no use of the word "package", so I assume that reading that (long) document won't ansnwer my question...
Thank you,
Frederik
The users-guide says "There is one major restriction: breakpoints and single-stepping are only available in interpreted modules; compiled code is invisible to the debugger." The modules of an installed package are always compiled, I think. If you have the source available, you could try to put that in your working directory (probably hide the installed package before starting ghci). Cheers, Daniel

On Sun, Feb 24, 2008 at 02:36:08AM +0100, Daniel Fischer wrote:
Am Sonntag, 24. Februar 2008 02:18 schrieb Frederik Eaton:
Hello,
I have a program which uses some code in a package, and I would like to be able to find out the source of an error which is occuring inside that package. Can I use the ghci-debugger to do this? If I try to set a breakpoint inside the package, it says:
"cannot set breakpoint on Vector.Sparse.Wrappers.vmergeOp: module Vector.Sparse.Wrappers is not interpreted"
But this page:
http://www.haskell.org/ghc/dist/current/docs/users_guide/ghci-debugger.html
has no use of the word "package", so I assume that reading that (long) document won't ansnwer my question...
Thank you,
Frederik
The users-guide says "There is one major restriction: breakpoints and single-stepping are only available in interpreted modules; compiled code is invisible to the debugger."
The modules of an installed package are always compiled, I think.
That's what I think as well, but I'm not sure (and it seems like the documentation should mention that: CC'ing glasgow-haskell-bugs). I can't see a reason why an installed package wouldn't be able to contain its own source code, for instance...
If you have the source available, you could try to put that in your working directory (probably hide the installed package before starting ghci).
Thanks, I may try that. I'm currently trying to get my GNU-make-based build to install profiling versions of package modules, in the hope that -xc might give more useful information than it did a year ago... Frederik -- http://ofb.net/~frederik/

Frederik Eaton wrote:
Thanks, I may try that. I'm currently trying to get my GNU-make-based build to install profiling versions of package modules, in the hope that -xc might give more useful information than it did a year ago...
I would think the chances of that are fairly low, there haven't been any significant changes to the way cost centres work. Cheers, Simon

On Mon, Feb 25, 2008 at 11:14:08AM +0000, Simon Marlow wrote:
Frederik Eaton wrote:
Thanks, I may try that. I'm currently trying to get my GNU-make-based build to install profiling versions of package modules, in the hope that -xc might give more useful information than it did a year ago...
I would think the chances of that are fairly low, there haven't been any significant changes to the way cost centres work.
OK thanks... Actually I got the GHCi debugger to help me (having discovered -fbreak-on-exception). Frederik P.S. Here are some suggestions for the GHCi debugger documentation: http://www.haskell.org/ghc/dist/current/docs/users_guide/ghci-debugger.html "There is one major restriction: breakpoints and single-stepping are only available in interpreted modules; compiled code is invisible to the debugger." --> "There is one major restriction: breakpoints and single-stepping are only available in interpreted modules; compiled code is invisible to the debugger. Note that packages only contain compiled code - so debugging a package requires finding its source and loading that directly." "There is currently no support for obtaining a "stack trace", but the tracing and history features provide a useful second-best, which will often be enough to establish the context of an error." --> "There is currently no support for obtaining a "stack trace", but the tracing and history features provide a useful second-best, which will often be enough to establish the context of an error. For instance, it is possible to break automatically when an exception is thrown, even if it is thrown from within compiled code (see 3.5.6. Debugging exceptions)."

Frederik Eaton wrote:
P.S. Here are some suggestions for the GHCi debugger documentation:
http://www.haskell.org/ghc/dist/current/docs/users_guide/ghci-debugger.html
"There is one major restriction: breakpoints and single-stepping are only available in interpreted modules; compiled code is invisible to the debugger." --> "There is one major restriction: breakpoints and single-stepping are only available in interpreted modules; compiled code is invisible to the debugger. Note that packages only contain compiled code - so debugging a package requires finding its source and loading that directly."
"There is currently no support for obtaining a "stack trace", but the tracing and history features provide a useful second-best, which will often be enough to establish the context of an error." --> "There is currently no support for obtaining a "stack trace", but the tracing and history features provide a useful second-best, which will often be enough to establish the context of an error. For instance, it is possible to break automatically when an exception is thrown, even if it is thrown from within compiled code (see 3.5.6. Debugging exceptions)."
Thanks! I'll push these changes. Cheers, Simon
participants (3)
-
Daniel Fischer
-
Frederik Eaton
-
Simon Marlow