OCamldebug breakpoint issues (fwd)

OCamldebug breakpoint issues (fwd)

[Nathaniel J. Gaylinn]

I'm having trouble dealing with breakpoints in OCamldebug. The documentation 
seems to make it clear that you can set a breakpoint at any event in your 
program, but ONLY at an event. This makes sense to me.

The problem is, in practice, I can't seem to set a breakpoint at an arbitrary 
event.

For starters, I used "info events Bignum" to get a list of events for my module 
(its name is Bignum). Fine. I get a long list of event points.

Then I started trying to set breakpoints at each event one after the other. 
That's when I began to see odd behavior.

I can set breakpoints at some events with no difficulty. For instance, "break @ 
Bignum #31" sets a breakpoint at offset 31 just as it should. With other 
events, instead of setting a breakpoint where I requested, the breakpoint is 
put at some earlier event. For instance, "break @ Bignum #50" sets a breakpoint 
at offset 31. This is odd, since as far as I know I should be able to set a 
breakpoint at any event. Usually this earlier event is the one right before the 
event I requested, but sometimes its as many as three events back.

What's truly baffling to me, though, is this: if I try to set an event at 
offset 185 (break @ Bignum #185) a breakpoint is created at offset 168, the 
event before the one I requested. However, when I try to set a breakpoint at 
offset 208, I get a breakpoint set at offset 185!!!

Either something's very wrong here, or I have a fundamental misunderstanding 
about how the debugger works with breakpoints. Any tips or suggestions would be 
greatly appreciated. For reference, the file I refer to in this email is 
attached for reference.

Thank you,

   -- Nate




bignum.ml:

let rec longAddWithoutCarry =
  function
  [], x -> x
  | x, [] -> x
  | hd1 :: tl1, hd2 :: tl2 -> hd1 + hd2 :: longAddWithoutCarry (tl1, tl2)

let longAdd (lst1, lst2) =
  let rec helper = function
  [], [], 0 -> []
  | [], [], carry -> [carry]
  | [], hd :: tl, carry -> (hd + carry) mod 10 :: helper ([], tl, (hd + 
carry) / 10)
  | hd :: tl, [], carry -> (hd + carry) mod 10 :: helper (tl, [], (hd + 
carry) / 10)
  | hd1 :: tl1, hd2 :: tl2, carry -> (hd1 + hd2 + carry) mod 10 :: helper 
(tl1, tl2, (hd1 + hd2 + carry) / 10)
  in
  helper (lst1, lst2, 0)

let multAll prod lst = List.map (fun x -> x * prod) lst
let timesTen lst = 0 :: lst

let rec longMult = function
  [], num2 -> []
  | hd :: tl, num2 -> longAdd (multAll hd num2, timesTen (longMult (tl, 
num2)));;


longMult ([3; 2; 1], [2; 1]);;
longMult ([2; 1], [3; 2; 1]);;
longMult ([9; 7; 6; 5; 4; 3; 2; 1], [8; 1]);;
longMult ([], [9; 9; 9; 9; 9; 9]);;
longMult ([1], [9; 9; 9; 9; 9; 9]);;
longMult ([1; 1; 1; 1; 1; 1; 1; 1; 1], [1; 1; 1; 1; 1; 1; 1; 1; 1]);;

let rec forever a = forever a;;

Re: [Caml-list] OCamldebug breakpoint issues

[Nathaniel J. Gaylinn]

I've gotten no responce to my concerns about setting breakpoints in OCaml 
code; does this mean that other people have also seen this behavior? Is it 
the case that the debugger can't set a breakpoint at some arbitrary event, 
or am I just doing it wrong? I really want to believe that there's a 
reasonable way to do this, because without one the whole breakpoint 
feature is rather useless.

Has anyone else observed ocamldebug misplacing requested breakpoints? If 
not, can someone try setting breakpoints in my code (included in a 
previous email) to see if there's something in there that's causing the 
problem? If not, I'm running Ocamldebug 3.08.3, which I'm pretty sure is 
the most up-to-date copy. Is there something wrong with my copy of 
ocamldebug?

Please help me try to see what I'm doing wrong, or at least let me know 
whether or not you've observed this problem in your code or mine. Any 
input on this matter would be greatly appreciated!

   -- Nate Gaylinn

Re: [Caml-list] OCamldebug breakpoint issues (fwd)

[Hendrik Tews]

"Nathaniel J. Gaylinn" <ngaylinn@cs.brown.edu> writes:

   I'm having trouble dealing with breakpoints in OCamldebug. The

I can reproduce all the things you describe. I guess you hit some
location translation problem. You should file a bug report (the
ocaml maintains sometimes miss an email on the list).

The "info events Bignum" yields

    Module : Bignum
       Address  Character      Kind      Repr.
         14332         31  pseudo/fun     (repr)
         14480         50      before      14332
         14456         64      before      14332
         14408         95      before      14332
         14428        138   after/ret           
         15204        152  pseudo/fun      15224
         15224        168      before     (repr)
         14724        185  pseudo/fun     (repr)
         15192        208      before      14724

Could someone please explain what the kind and repl columns mean?
(The strings "kind" and "repl" do not occur in the debugger
manual.) 

As the numbers match one could think that the events at #50, #64,
and #95 are aliases for #31. Looking at the source, one could
imagine #50 and #64 being the same (function exit), however,
#95 should be very different from #31.

   What's truly baffling to me, though, is this: if I try to set an event
   at offset 185 (break @ Bignum #185) a breakpoint is created at offset
   168, the event before the one I requested. However, when I try to set
   a breakpoint at offset 208, I get a breakpoint set at offset 185!!!

This is indeed very strange.

   Then I started trying to set breakpoints at each event one after the
   other. That's when I began to see odd behavior.
   
BTW, why don't you use the single stepping feature, if you want
to break at every event?

Bye,

Hendrik

Re: [Caml-list] OCamldebug breakpoint issues (fwd)

[Nathaniel J. Gaylinn]

>   Then I started trying to set breakpoints at each event one after the
>   other. That's when I began to see odd behavior.
>
> BTW, why don't you use the single stepping feature, if you want
> to break at every event?

Because I wanted to test the breakpoint feature and see if it would break 
at any event I asked for  :)

That's the frustrating thing to me about this breakpoints problem, it's a 
serious thing that should be dealt with, but there are several other ways 
of more-or-less doign the same thing with stepping/goto and whatnot. 
Somehow that sort of belittles the problem where I feel it should be 
handled directly and taken quite seriously.

Oh well, I'll submit a bug report. Thanks for giving me some sort of 
validation  ;)

   -- Nate