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.

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

Module aliases break debugging with ocamldebug #6841

Closed
vicuna opened this issue Apr 15, 2015 · 9 comments
Closed

Module aliases break debugging with ocamldebug #6841

vicuna opened this issue Apr 15, 2015 · 9 comments

Comments

@vicuna
Copy link

vicuna commented Apr 15, 2015

Original bug ID: 6841
Reporter: jordojw
Assigned to: @garrigue
Status: closed (set by @xavierleroy on 2016-12-07T10:47:36Z)
Resolution: fixed
Priority: high
Severity: major
Platform: Mac
OS: OS X
OS Version: 10.10
Version: 4.02.1
Fixed in version: 4.02.2+dev / +rc1
Category: tools (ocaml{lex,yacc,dep,debug,...})
Related to: #6270
Monitored by: @hhugo @yallop

Bug description

First, I apologize if this is not major/high priority. I'm still calibrating the importance of bugs/breaks, but I considered this a major issue because I'm not aware of any quick fixes to the issue (I tried the mailing list) to unblock development/debugging. In short, module aliases can break debugging - I've included the message from the mailing list that explains a quick reproduction of the error:
(Mailing List Message Below):

Module aliases are the encouraged way of grouping modules together. They have worked fine up until the point where I tried to use ocamldebug with them.

Module aliases allow development in the large, by permitting namespacing. I couldn't imagine building anything but a toy project with a few engineers with the restriction that no two files have the same basename! Module aliases to the rescue (thanks to Leo White for the suggestion). But, it seems that module aliases with namespacing make ocamldebug completely unusable. Here's a minimal repro case below. There are two simple namespaces each with a submodules in files named "test.ml". I am using module aliases to namespace them so that there are no collisions. Again, this works fine with everything except the debugger.

I hope I'm just doing something incorrect - if that is the case, I thank you in advance for your patience.

Steps to reproduce

Compile project using module aliases

mkdir ~/Desktop/testOne/
mkdir ~/Desktop/testTwo/
echo "let x () = print_string \"hello from test one\"" > ~/Desktop/testOne/test.ml
echo "let x () = print_string \"hello from test two\"" > ~/Desktop/testTwo/test.ml
echo "module Test = NamespaceOne_test" > ~/Desktop/testOne/namespaceOne.ml
echo "module Test = NamespaceOne_test" > ~/Desktop/testOne/namespaceOne.mli
echo "module Test = NamespaceTwo_test" > ~/Desktop/testTwo/namespaceTwo.ml
echo "module Test = NamespaceTwo_test" > ~/Desktop/testTwo/namespaceTwo.mli
echo 'NamespaceOne.Test.x (); NamespaceTwo.Test.x ()' > ~/Desktop/prog.ml

# Generate namespaced module aliases
ocamlc -g -c -no-alias-deps -w -49 -I ~/Desktop/testOne/ -o ~/Desktop/testOne/namespaceOne -intf ~/Desktop/testOne/namespaceOne.mli -o ~/Desktop/testOne/namespaceOne -impl ~/Desktop/testOne/namespaceOne.ml
ocamlc -g -c -no-alias-deps -w -49 -I ~/Desktop/testTwo/ -o ~/Desktop/testTwo/namespaceTwo -intf ~/Desktop/testTwo/namespaceTwo.mli -o ~/Desktop/testTwo/namespaceTwo -impl ~/Desktop/testTwo/namespaceTwo.ml

ocamlc -g -c -I ~/Desktop/testOne/ -open NamespaceOne -o ~/Desktop/testOne/namespaceOne_test -impl ~/Desktop/testOne/test.ml
ocamlc -g -c -I ~/Desktop/testTwo/ -open NamespaceTwo -o ~/Desktop/testTwo/namespaceTwo_test -impl ~/Desktop/testTwo/test.ml
ocamlc -g -c -I ~/Desktop -I ~/Desktop/testOne/ -I ~/Desktop/testTwo/ -o ~/Desktop/prog.cmo -impl ~/Desktop/prog.ml

ocamlc -g -I ~/Desktop/testTwo/ -I ~/Desktop/testOne/ ~/Desktop/testOne/namespaceOne.cmo ~/Desktop/testTwo/namespaceTwo.cmo ~/Desktop/testOne/namespaceOne_test.cmo ~/Desktop/testTwo/namespaceTwo_test.cmo ~/Desktop/prog.cmo -o ~/Desktop/prog.out


# Start ocamldebug

ocamldebug ~/Desktop/prog.out

# Run these commands inside of ocamldebug

directory ~/Desktop/
directory ~/Desktop/testOne/
directory ~/Desktop/testTwo/

# This doesn't work but that makes sense - there aren't any modules named
# "Test", there's one named NamespaceOne_test and one named
# NamespaceTwo_test.

break @Test 1

# But - neither of the namespaced modules work either!
# -----------------------------------------------------------------------

break @NamespaceOne_test 1
break @NamespaceTwo_test 1

Additional information

Here is proof that ocamldebug works correctly without namespacing/module aliases:

Working project without module aliases:

mkdir ~/Desktop/testOne/
mkdir ~/Desktop/testTwo/
echo "let x () = print_string \"hello from test one\"" > ~/Desktop/testOne/testOneNamespaceNotNeeded.ml
echo "let x () = print_string \"hello from test two\"" > ~/Desktop/testTwo/testTwoNamespaceNotNeeded.ml
echo 'TestOneNamespaceNotNeeded.x (); TestTwoNamespaceNotNeeded.x ()' > ~/Desktop/prog.ml

ocamlc -g -c -I ~/Desktop/testOne/ -o ~/Desktop/testOne/testOneNamespaceNotNeeded -impl ~/Desktop/testOne/testOneNamespaceNotNeeded.ml
ocamlc -g -c -I ~/Desktop/testTwo/ -o ~/Desktop/testTwo/testTwoNamespaceNotNeeded -impl ~/Desktop/testTwo/testTwoNamespaceNotNeeded.ml
ocamlc -g -c -I ~/Desktop -I ~/Desktop/testOne/ -I ~/Desktop/testTwo/ -o ~/Desktop/prog.cmo -impl ~/Desktop/prog.ml

ocamlc -g -I ~/Desktop/testTwo/ -I ~/Desktop/testOne/  ~/Desktop/testOne/testOneNamespaceNotNeeded.cmo ~/Desktop/testTwo/testTwoNamespaceNotNeeded.cmo ~/Desktop/prog.cmo -o ~/Desktop/prog.out

ocamldebug ~/Desktop/prog.out

# Run these commands inside of ocamldebug. Working correctly.
directory ~/Desktop/
directory ~/Desktop/testOne/
directory ~/Desktop/testTwo/
break @TestOneNamespaceNotNeeded 1

File attachments

@vicuna
Copy link
Author

vicuna commented Apr 16, 2015

Comment author: @garrigue

It would have helped a lot to give the error message :-)

No source file for NamespaceOne_test.

The problem is that the original source file name is not kept in the debugging information.
Looking for a solution... but there are already some terrible hacks in the code.

@vicuna
Copy link
Author

vicuna commented Apr 16, 2015

Comment author: @garrigue

By the way, there are two workarounds to the problem (until we have a real solution).

  1. Do not use the "break @ file line" syntax.
    The "break NamespaceOne_test.x" syntax works.
    And once you are in the file, the "break @ line" syntax works too.

  2. Allow to refer to the source file through the long name:
    ln -s test.ml namespaceOne_test.ml

These are stop-gaps, but should help you.

@vicuna
Copy link
Author

vicuna commented Apr 16, 2015

Comment author: @garrigue

Actually, you can also use the syntax
break @ file # char

With a good editor, this could be sufficient...

@vicuna
Copy link
Author

vicuna commented Apr 16, 2015

Comment author: @garrigue

The attached patch seems to fix the problem.
Is there anything wrong in using the file name of the location as default, when the file actually exists?

@vicuna
Copy link
Author

vicuna commented Apr 16, 2015

Comment author: @damiendoligez

For reference, this is related to the following PRs:

#6270
#14
#58
#157

@vicuna
Copy link
Author

vicuna commented Apr 16, 2015

Comment author: jordojw

Actually, you can also use the syntax
break @ file # char

It seems that doesn't work in 4.02.1. However, it seems that providing the compiled module name with a character place works, even though providing the compiled module name with the line number does not.

@vicuna
Copy link
Author

vicuna commented Apr 17, 2015

Comment author: @garrigue

jordojw

Sorry, there is not "break @ file # char" syntax, this is "break @ module # char".
So yes, you need to give it the compiled unit name, not the source name, which is natural as the source name would be ambiguous.
The reason using the line number does not work is that it tries to first open the source file to find the corresponding character position, and the logic used at this point uses only the module name.

@vicuna
Copy link
Author

vicuna commented Apr 17, 2015

Comment author: @garrigue

doligez

Actually, what my patch does is different from what I suggested on caml-devel.
It reuses the existing infrastructure, in particular the fact events contain absolute source paths. By looking up the first event of a module, one can find the source file absolute path.
So I think there is no overlap with the patches you mention.

In most cases this should be sufficient, except if the files have been moved around, in which case we fall back on the original logic. It would be possible to use the basename of the location rather than the module name, but it may well be ambiguous.

@vicuna
Copy link
Author

vicuna commented Apr 20, 2015

Comment author: @garrigue

Fixed at revisions 16022 and 16023 in trunk and 4.02.
Follows the patch (but with correct error reporting).
That is, first look for a source file where it was when compiled.
If this fails, try the old logic of searching the source by name, but of course it will fail if you used -o to change the name...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants