Original bug ID: 3732
Reporter: administrator
Status: closed (set by @damiendoligez on 2005-12-15T14:11:38Z)
Resolution: not a bug
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)
Parent of: #3759 #3765 #3766

Bug description

Full_Name: Nathan Gaylinn
Version: 3.08.3
OS: Debian Linux
Submission from: point.cs.brown.edu (128.148.33.31)

I'm trying to write an IDE for OCaml as a summer project, and in my efforts to
try to make a nice GUI wrapper around the debugger I found what seems to be a
rather unpleasant bug.

Setting breakpoints based on character offset doesn't always work. Here are some
specific examples of what I've seen:

When I try to set a breakpoint at offset 31 in my program like so:
break @ Bignum #31
the debugger will happily create a breakpoint at offset 31 in my program. Great.

However, with other events, instead of setting a breakpoint where I requested,
the new breakpoint will show up at some earlier event. For instance, a
breakpoint request at offsets 50, 64, or 95 will also end up at offset 31. These
are all proper event locations because "info events Bignum" reports all of them.
This is frustrating, and it suggests that ocamldebug is somehow skipping over
certain breakpoints. The piece that really doesn't fit with the puzzle, though,
is this:

If I try to set an event at offset 185, a breakpoint is created at offset 168,
the event just before the one I wanted. However, when I try to set a breakpoint
at offset 208, ocamldebug creates a breakpoint at offset 185! This shows that
ocamldebug isn't just skipping certain breakpoints. It skips over some
breakpoints some times, but at other times succeeds in finding them.

To be honest, I don't find setting breakpoints all that useful in ocamldebug
considering the many other powerful features, and it's not that hard to get
around this problem. However, since I'm trying to write a GUI for the debugger,
it's rather important that it behave as its expected to. Clicking on an event
point and asking for a breakpoint there and then having one set two lines
previous in your code is quite maddening, and simply will not do. To get past
this problem, I may just remove the breakpoint features from my debugger
entirely (the user will still be able to set breakpoints, he'll just have to do
so manually by typing out the command).

In any case, I wanted to bring this bug to your attention and would be very
interested to know about it when you might get a chance to fix it. I'm hoping to
have my program available in the next few months both for Linux/OSX and for
Windows (using OCaml via Cygwin).

Thank you very much,
-- Nate Gaylinn

For convenience, here is the code I referred to in the body of this report:

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;;