Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0004788OCamlOCaml generalpublic2009-05-08 17:072013-08-02 15:57
Reportersacerdot 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version3.11.0 
Target Version4.01.0+devFixed in Version4.01.0+dev 
Summary0004788: Highly misleading error message
DescriptionDebug symbols for executables compiled with -g are read directly from the executable file, but the latter is searched in the current directory. Thus,
if the program does a Sys.chdir to another directory, the executable is not found. The very misleading error message the user gets is "(Program not linked with -g, cannot print stack backtrace)" in place of "Executable program not found in $CURRENTDIR". Obviously, an even better solution would be to always look for the executable in the path the program was launched.

The program in attachment shows the problem (unless you run it from /tmp, of course :-)
TagsNo tags attached.
Attached Files? file icon foo.ml [^] (64 bytes) 2009-05-08 17:07 [Show Content]

- Relationships
related to 0003928closed Executable linked with -g does not produce a stack backtrace 

-  Notes
(0004953)
db (reporter)
2009-05-08 18:34

Really? My impression was that under Linux bytecode full path is taken on startup from /proc/self/exe. Other OSes search system $PATH for argv[0]. In both cases current directory should not affect the process. But I agree that something like "Bytecode file not found, cannot print stack backtrace" would be better.
(0004954)
doligez (administrator)
2009-05-15 17:08

The executable file is looked up in the PATH, except of course when it's invoked without using the PATH (for example, as ./a.out).

We need to fix the error message, but we can't do much to get rid of the error itself.
(0010079)
doligez (administrator)
2013-08-02 15:57
edited on: 2013-08-02 16:11

I've changed the error message in case the executable file is not found (branch 4.01, rev 13966 and 13967).

The solution is not perfect, because when the current directory contains another a.out compiled by OCaml with symbols, you get a bogus backtrace instead of an error message. Backtraces are for debugging, so I guess we can live with this.


- Issue History
Date Modified Username Field Change
2009-05-08 17:07 sacerdot New Issue
2009-05-08 17:07 sacerdot File Added: foo.ml
2009-05-08 18:34 db Note Added: 0004953
2009-05-15 17:08 doligez Note Added: 0004954
2009-05-15 17:08 doligez Status new => acknowledged
2009-08-25 09:59 xclerc Relationship added related to 0003928
2012-07-11 14:52 doligez Target Version => 4.01.0+dev
2012-07-31 13:36 doligez Target Version 4.01.0+dev => 4.00.1+dev
2012-09-17 13:56 doligez Target Version 4.00.1+dev => 4.00.2+dev
2013-07-09 17:27 doligez Target Version 4.00.2+dev => 4.01.0+dev
2013-08-02 15:57 doligez Note Added: 0010079
2013-08-02 15:57 doligez Status acknowledged => resolved
2013-08-02 15:57 doligez Resolution open => fixed
2013-08-02 15:57 doligez Fixed in Version => 4.01.0+dev
2013-08-02 16:11 doligez Note Edited: 0010079 View Revisions


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker