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

two backtrace problems #3027

Closed
vicuna opened this issue Nov 14, 2001 · 2 comments
Closed

two backtrace problems #3027

vicuna opened this issue Nov 14, 2001 · 2 comments
Labels

Comments

@vicuna
Copy link

vicuna commented Nov 14, 2001

Original bug ID: 629
Reporter: administrator
Status: closed
Resolution: fixed
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)

Bug description

Hi,

at http://wwwtcs.inf.tu-dresden.de/~tews/Trace/trace.tar.gz
you find the sources that reproduce two problems with backtraces:

  1. The trace starts with "Raised at module Format", although the
    assertion fails in module Pvs_pretty,

  2. there are lots of lines "Called from unknown location"
    although everything is compiled with -g and Dynlink is not
    used.

To reproduce the problem
cd Bug/Ccsl
make # you need GNU make here
export OCAMLRUNPARAM=b=1
./run

The assertion is triggered because method raise_bug in
interface_theory.ml puts an empty list the constructor
SmartApplication. I tried to reduce the size of the example
further, but as soon as I delete other substantial parts the
problem goes away. This happens also, if I put a comment around
the unused code in file interface_theory.ml (everything below
class ccsl_interface_theory).

Bye,

Hendrik

@vicuna
Copy link
Author

vicuna commented Nov 15, 2001

Comment author: administrator

at http://wwwtcs.inf.tu-dresden.de/~tews/Trace/trace.tar.gz
you find the sources that reproduce two problems with backtraces:

Thanks for the nicely packaged source, I was able to reproduce and
understand the problem.

  1. there are lots of lines "Called from unknown location"
    although everything is compiled with -g and Dynlink is not
    used.

This is indeed a stupid bug in the backtrace handling code (wrong
pointer arithmetic). A patch (against byterun/backtrace.c) is
enclosed below if you wish to test the fix.

  1. The trace starts with "Raised at module Format", although the
    assertion fails in module Pvs_pretty,

This is more subtle. The backtrace code tries to handle intelligently
exception finalization code like the below:

    try
      ...
    with x ->
      (* do some finalization *);
      raise x

That is, it tries not to say that the exception was raised at "raise x"
above, but keep track of where it was raised in "...".

In your particular case, however, the finalization code calls some
functions from Formatter that raise and catch exceptions. This confuses
the backtrace code, which now believes that the exception re-raised at
"raise x" is actually the one raised by the Formatter functions.

You can boil this down to:

let _ =
try
raise (Failure "foo") (A)
with x ->
begin try raise Exit (B) with Exit -> () end;
raise x (C)

The trace printed is

    raised at B
    re-raised at C

instead of

    raised at A
    re-raised at C

I believe the best we can get (without incurring excessive Java-like
execution overhead on exceptions) is

    raised at C

i.e. you'll get a backtrace that is correct, but not as detailed as
you'd have liked.

Best wishes,

  • Xavier Leroy

diff -u -r1.6 backtrace.c
--- backtrace.c 2001/10/09 15:13:58 1.6
+++ backtrace.c 2001/11/15 12:46:16
@@ -49,7 +49,7 @@

void stash_backtrace(code_t pc, value * sp)
{

  • code_t end_code = start_code + code_size;
  • code_t end_code = (code_t) ((char *) start_code + code_size);
    if (pc != NULL) pc = pc - 1;
    if (backtrace_pos >= BACKTRACE_BUFFER_SIZE) return;
    if (backtrace_buffer == NULL) {

@vicuna
Copy link
Author

vicuna commented Nov 26, 2001

Comment author: administrator

Revised backtrace handling 2001-11-26 by XL.

@vicuna vicuna closed this as completed Nov 26, 2001
@vicuna vicuna added the bug label Mar 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant