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

program compiled with ocamlc segfaults #8191

Closed
vicuna opened this issue Jun 27, 2003 · 3 comments
Closed

program compiled with ocamlc segfaults #8191

vicuna opened this issue Jun 27, 2003 · 3 comments
Labels

Comments

@vicuna
Copy link

vicuna commented Jun 27, 2003

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

Bug description

Dear Camllists,

I hope this is another false alarm and I am just doing something stupid.

A large program compiled with ocamlc segfaults. I know that a program
compiled with ocamlopt can segfault if it runs out of stack, but I
believe this is not supposed to be possible with ocamlc.

When I run the program using ocamldebug, I get

Lost connection with process 3014 (active process)
between time 3190000 and time 3200000
Trying to recover...

When I run the program under gdb, I get the following output:

: nr@labrador 2314 ; gdb ../bin/qc--
gdb: Symbol `emacs_ctlx_keymap' has different size in shared object, consider re-linking
GNU gdb 2002-04-01-cvs
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-linux"...(no debugging symbols found)...
(gdb) run testdrv.lua all.dummy.tst
Starting program: /amd/lair60/vol/vol0/home/nr/c--/qc--/bin/qc-- testdrv.lua all.dummy.tst
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...[New Thread 16384 (LWP 3336)]

(no debugging symbols found)...(no debugging symbols found)... [ 75.76 % ]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 3336)]
0x0805f57b in alloc_channel ()
(gdb) bt
#0 0x0805f57b in alloc_channel ()
#1 0x0805f626 in caml_out_channels_list ()
#2 0x08067566 in interprete ()
#3 0x080686a1 in caml_main ()
#4 0x0805ad1c in main ()
#5 0x400e6a51 in __libc_start_main () from /lib/libc.so.6
(gdb)

Please let me know how I can provide more information that might help
you (or me) diagnose and repair this problem.

Norman

@vicuna
Copy link
Author

vicuna commented Jun 30, 2003

Comment author: administrator

Dear Norman,

A large program compiled with ocamlc segfaults. I know that a program
compiled with ocamlopt can segfault if it runs out of stack, but I
believe this is not supposed to be possible with ocamlc.
[...]
#0 0x0805f57b in alloc_channel ()
#1 0x0805f626 in caml_out_channels_list ()
#2 0x08067566 in interprete ()
#3 0x080686a1 in caml_main ()
#4 0x0805ad1c in main ()
#5 0x400e6a51 in __libc_start_main () from /lib/libc.so.6
(gdb)

This looks interesting -- alloc_channel isn't a place where I would
have expected a crash :-)

Please let me know how I can provide more information that might help
you (or me) diagnose and repair this problem.

If you could send me a self-contained program that reproduces the
crash, I'll be happy to investigate.

  • Xavier

@vicuna
Copy link
Author

vicuna commented Jul 29, 2003

Comment author: administrator

Dear Norman,

A large program compiled with ocamlc segfaults. I know that a program
compiled with ocamlopt can segfault if it runs out of stack, but I
believe this is not supposed to be possible with ocamlc.
#0 0x0805f57b in alloc_channel ()
#1 0x0805f626 in caml_out_channels_list ()
#2 0x08067566 in interprete ()

Thanks for the nicely packaged sources. I was able to reproduce the
crash easily, and understand it after a bit more effort. It turns out to
be a genuine bug in alloc_channel due to concurrent finalization and
reallocation of an I/O channel. A patch is included below. It is
against 3.07beta1 but I think it should apply cleanly to 3.06.

Best,

  • Xavier

Index: csl/byterun/io.c
diff -c csl/byterun/io.c:1.62 csl/byterun/io.c:1.63
*** csl/byterun/io.c:1.62 Mon Jan 6 11:59:07 2003
--- csl/byterun/io.c Tue Jul 29 13:48:34 2003


*** 430,439 ****

CAMLexport value alloc_channel(struct channel *chan)
{
! value res = alloc_custom(&channel_operations, sizeof(struct channel *),
! 1, 1000);
Channel(res) = chan;

  • chan->refcount++;
    return res;
    }

--- 430,439 ----

CAMLexport value alloc_channel(struct channel chan)
{
! value res;
! chan->refcount++; /
prevent finalization during next alloc */
! res = alloc_custom(&channel_operations, sizeof(struct channel *), 1, 1000);
Channel(res) = chan;
return res;
}

@vicuna
Copy link
Author

vicuna commented Jul 29, 2003

Comment author: administrator

Fixed 2003-07-29 by XL

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