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

Re: [Caml-list] Thank you for backtraces! #2690

Closed
vicuna opened this issue Feb 26, 2001 · 14 comments
Closed

Re: [Caml-list] Thank you for backtraces! #2690

vicuna opened this issue Feb 26, 2001 · 14 comments
Labels

Comments

@vicuna
Copy link

vicuna commented Feb 26, 2001

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

Bug description

On Mon, Feb 26, 2001 at 03:54:27PM +0100, Xavier Leroy wrote:

The current CVS version of ocaml contains backtraces; example:
This feature will really help developers a lot. Thanks to the Caml team!

That was a modest hack; I'm glad you find it useful!

By the way: the OCaml code was frozen in preparation for the 3.01
release, so if you wish to beta-test it on your favorite programs, now
is a good time to download the working sources from http://camlcvs.inria.fr/
and give it a good test! Report any problems you may have to
caml-bugs@inria.fr.

mmm, ...

Je vient juste d'essayer, et :

boot/ocamlrun ./ocamlopt -I stdlib -I utils -I parsing -I typing -I bytecomp
-I asmcomp -I driver -I toplevel -c typing/typetexp.ml
boot/ocamlrun ./ocamlopt -I stdlib -I utils -I parsing -I typing -I bytecomp
-I asmcomp -I driver -I toplevel -c typing/typecore.ml
make[1]: *** [typing/typecore.cmx] Erreur de segmentation

Ceci est arrive (2 fois deja) lors de la compilation du package debian ocaml,
sur une machine bi-celeron (Abit BP-6) avec debian/unstable, glibc 2.2.2 et un
noyau 2.4.1.

Si vous avez besoin de plus d'info a ce propos, je suis a votre disposition,
...

Amicalement,

Sven Luther

@vicuna
Copy link
Author

vicuna commented Feb 27, 2001

Comment author: administrator

boot/ocamlrun ./ocamlopt -I stdlib -I utils -I parsing -I typing -I bytecomp
-I asmcomp -I driver -I toplevel -c typing/typetexp.ml
boot/ocamlrun ./ocamlopt -I stdlib -I utils -I parsing -I typing -I bytecomp
-I asmcomp -I driver -I toplevel -c typing/typecore.ml
make[1]: *** [typing/typecore.cmx] Erreur de segmentation

Ceci est arrive (2 fois deja) lors de la compilation du package
debian ocaml, sur une machine bi-celeron (Abit BP-6) avec
debian/unstable, glibc 2.2.2 et un noyau 2.4.1.

Est-ce que le plantage est reproductible? (Se produit toujours,
toujours sur le même fichier source.) Si non, cela sent le problème
hardware: mauvaise mémoire ou surchauffe. (En particulier, les
bi-Celeron sont réputés pour des problèmes de surchauffe du "chipset"...)

Si vous avez besoin de plus d'info a ce propos, je suis a votre
disposition, ...

Un truc qui vaut la peine d'essayer:

You can also build a debug version of the runtime system. Go to the
byterun/ directory and do "make ocamlrund". Then, copy ocamlrund to
../boot/ocamlrun, and try again. This version of the runtime system
contains lots of assertions and sanity checks that could help you
pinpoint the problem.

Tiens-nous au courant,

  • Xavier Leroy

@vicuna
Copy link
Author

vicuna commented Feb 27, 2001

Comment author: administrator

On Tue, Feb 27, 2001 at 10:21:42AM +0100, Xavier Leroy wrote:

boot/ocamlrun ./ocamlopt -I stdlib -I utils -I parsing -I typing -I bytecomp
-I asmcomp -I driver -I toplevel -c typing/typetexp.ml
boot/ocamlrun ./ocamlopt -I stdlib -I utils -I parsing -I typing -I bytecomp
-I asmcomp -I driver -I toplevel -c typing/typecore.ml
make[1]: *** [typing/typecore.cmx] Erreur de segmentation

Ceci est arrive (2 fois deja) lors de la compilation du package
debian ocaml, sur une machine bi-celeron (Abit BP-6) avec
debian/unstable, glibc 2.2.2 et un noyau 2.4.1.

Est-ce que le plantage est reproductible? (Se produit toujours,
toujours sur le même fichier source.) Si non, cela sent le problème
hardware: mauvaise mémoire ou surchauffe. (En particulier, les
bi-Celeron sont réputés pour des problèmes de surchauffe du "chipset"...)

mmm, ....

la premiere fois, je croyait que c'etait du a un manque de place sur le
disque, (il n'y avait plus de place sur la partition). Mais apres que j'ai
fait de la place, cela a de nouveau planter, je crois au meme endroit, mais je
ne suis pas trop sur. Maintenant je suis en train de relancer un make
bootstrap, et cela a l'air de marcher, mmm, bizzare, je n'ai jamais eu de
probleme precedement avec mon bi-celeron, et cela fait 1 ans maintenant que je
compile le package caml et bien d'autre dessus. Peut-etre que j'ai fait une
upgrade depuis, il faudrait que je teste.

En tout cas, je relance un build complet et vous tient au courrant.

mmm, c'est pas dans make bootstrap qu'est le probleme, mais dans make opt ou
opt.opt, je pense, ...

Si vous avez besoin de plus d'info a ce propos, je suis a votre
disposition, ...

Un truc qui vaut la peine d'essayer:

You can also build a debug version of the runtime system. Go to the
byterun/ directory and do "make ocamlrund". Then, copy ocamlrund to
../boot/ocamlrun, and try again. This version of the runtime system
contains lots of assertions and sanity checks that could help you
pinpoint the problem.

Tiens-nous au courant,

D'accord, si le probleme persiste, j'essayerai cela.

BTW, est-il possible de construire labltk avec tcl/tk 8.3 ? jusqu'a maintenant
je compilait avec tcl/tk 8.0, mais comme c'est un nouveau package, j'aimerait
passer a quelque chose de plus recent.

(ne serait-ce que parceque le mainteneur de tcl/tk aimeriait supprimer tcl/tk
8.0 si possible, il y a deja 8.0, 8.2 et 8.3 (au moins) dans l'archive.

Amicalement,

Sven Luther

@vicuna
Copy link
Author

vicuna commented Feb 27, 2001

Comment author: administrator

On Tue, Feb 27, 2001 at 10:21:42AM +0100, Xavier Leroy wrote:

boot/ocamlrun ./ocamlopt -I stdlib -I utils -I parsing -I typing -I bytecomp
-I asmcomp -I driver -I toplevel -c typing/typetexp.ml
boot/ocamlrun ./ocamlopt -I stdlib -I utils -I parsing -I typing -I bytecomp
-I asmcomp -I driver -I toplevel -c typing/typecore.ml
make[1]: *** [typing/typecore.cmx] Erreur de segmentation

Ceci est arrive (2 fois deja) lors de la compilation du package
debian ocaml, sur une machine bi-celeron (Abit BP-6) avec
debian/unstable, glibc 2.2.2 et un noyau 2.4.1.

Est-ce que le plantage est reproductible? (Se produit toujours,
toujours sur le même fichier source.) Si non, cela sent le problème
hardware: mauvaise mémoire ou surchauffe. (En particulier, les
bi-Celeron sont réputés pour des problèmes de surchauffe du "chipset"...)

Non, c'est toujours au meme endroit :

boot/ocamlrun ./ocamlopt -I stdlib -I utils -I parsing -I typing -I bytecomp
-I asmcomp -I driver -I toplevel -c typing/typetexp.ml
boot/ocamlrun ./ocamlopt -I stdlib -I utils -I parsing -I typing -I bytecomp
-I asmcomp -I driver -I toplevel -c typing/typecore.ml
make[1]: *** [typing/typecore.cmx] Erreur de segmentation
make[1]: Leaving directory `/home/luther/debian/ocaml/cvs/ocaml-3.01-cvs'
make: *** [build-stamp] Erreur 2
luther@lambda:~/debian/ocaml/cvs/ocaml-3.01-cvs$ make opt

est-ce que vous voulez un log complet ?

je vais essayer le debug maintenant.

Amicalement,

Sven Luther

@vicuna
Copy link
Author

vicuna commented Feb 27, 2001

Comment author: administrator

On Tue, Feb 27, 2001 at 10:21:42AM +0100, Xavier Leroy wrote:

boot/ocamlrun ./ocamlopt -I stdlib -I utils -I parsing -I typing -I bytecomp
-I asmcomp -I driver -I toplevel -c typing/typetexp.ml
boot/ocamlrun ./ocamlopt -I stdlib -I utils -I parsing -I typing -I bytecomp
-I asmcomp -I driver -I toplevel -c typing/typecore.ml
make[1]: *** [typing/typecore.cmx] Erreur de segmentation

Ceci est arrive (2 fois deja) lors de la compilation du package
debian ocaml, sur une machine bi-celeron (Abit BP-6) avec
debian/unstable, glibc 2.2.2 et un noyau 2.4.1.

Est-ce que le plantage est reproductible? (Se produit toujours,
toujours sur le même fichier source.) Si non, cela sent le problème
hardware: mauvaise mémoire ou surchauffe. (En particulier, les
bi-Celeron sont réputés pour des problèmes de surchauffe du "chipset"..

J'arrive un peu plus loins maintenant :

luther@lambda:~/debian/ocaml/cvs/ocaml-3.01-cvs$ make opt.opt
boot/ocamlrun ./ocamlopt -I stdlib -I utils -I parsing -I typing -I bytecomp
-I asmcomp -I driver -I toplevel -c typing/typeclass.ml
make: *** [typing/typeclass.cmx] Erreur de segmentation

Je vais essayer de construire sur un athlon 500 juste pour tester.

Amicalement,

Sven Luther

@vicuna
Copy link
Author

vicuna commented Feb 27, 2001

Comment author: administrator

On Tue, Feb 27, 2001 at 10:21:42AM +0100, Xavier Leroy wrote:

boot/ocamlrun ./ocamlopt -I stdlib -I utils -I parsing -I typing -I bytecomp
-I asmcomp -I driver -I toplevel -c typing/typetexp.ml
boot/ocamlrun ./ocamlopt -I stdlib -I utils -I parsing -I typing -I bytecomp
-I asmcomp -I driver -I toplevel -c typing/typecore.ml
make[1]: *** [typing/typecore.cmx] Erreur de segmentation

Ceci est arrive (2 fois deja) lors de la compilation du package
debian ocaml, sur une machine bi-celeron (Abit BP-6) avec
debian/unstable, glibc 2.2.2 et un noyau 2.4.1.

Est-ce que le plantage est reproductible? (Se produit toujours,
toujours sur le même fichier source.) Si non, cela sent le problème
hardware: mauvaise mémoire ou surchauffe. (En particulier, les
bi-Celeron sont réputés pour des problèmes de surchauffe du "chipset"...)

Si vous avez besoin de plus d'info a ce propos, je suis a votre
disposition, ...

Un truc qui vaut la peine d'essayer:

You can also build a debug version of the runtime system. Go to the
byterun/ directory and do "make ocamlrund". Then, copy ocamlrund to
../boot/ocamlrun, and try again. This version of the runtime system
contains lots of assertions and sanity checks that could help you
pinpoint the problem.

Tiens-nous au courant,

mmm, ...

voici le log, j'espere que cela sera plus parlant pour vous que pour moi :

boot/ocamlrun ./ocamlopt -I stdlib -I utils -I parsing -I typing -I bytecomp -I asmcomp -I driver -I toplevel -c typing/typeclass.ml

O'Caml runtime: debug mode

Initial minor heap size: 128k bytes
Initial major heap size: 248k bytes
Initial space overhead: 42%
Initial max overhead: 1000000%
Initial heap increment: 248k bytes
Initial stack limit: 1024k bytes
Starting new major GC cycle

O'Caml runtime: heap check

!<>$<Growing heap to 496k bytes
Growing page table to 330 entries

$<>Starting new major GC cycle

O'Caml runtime: heap check

Growing gray_vals to 16k bytes
!<>!<>$<Growing heap to 744k bytes
Growing page table to 394 entries

$&lt;&gt;$&lt;>Starting new major GC cycle

O'Caml runtime: heap check

!<>!Growing heap to 992k bytes
Growing page table to 458 entries
<>!<>$<>$Growing heap to 1240k bytes
Growing page table to 522 entries
<>$<>$<>Starting new major GC cycle

O'Caml runtime: heap check

!<>!Growing heap to 1488k bytes
Growing page table to 586 entries
<>!<>!<>!<>!<Growing heap to 1736k bytes
Growing page table to 650 entries

$&lt;&gt;$&lt;>$<>$<>$<>$<Growing heap to 1984k bytes
Growing page table to 714 entries
$&lt;&gt;$&lt;>Starting new major GC cycle

O'Caml runtime: heap check

!<>!<>!<Growing heap to 2232k bytes
Growing page table to 778 entries

!<>!<>!<>!<>!<>!<>!<>!<>!<>!<Growing heap to 2480k bytes
Growing page table to 842 entries
!<>!make: *** [typing/typeclass.cmx] Erreur de segmentation

@vicuna
Copy link
Author

vicuna commented Feb 27, 2001

Comment author: administrator

On Tue, Feb 27, 2001 at 10:21:42AM +0100, Xavier Leroy wrote:

boot/ocamlrun ./ocamlopt -I stdlib -I utils -I parsing -I typing -I bytecomp
-I asmcomp -I driver -I toplevel -c typing/typetexp.ml
boot/ocamlrun ./ocamlopt -I stdlib -I utils -I parsing -I typing -I bytecomp
-I asmcomp -I driver -I toplevel -c typing/typecore.ml
make[1]: *** [typing/typecore.cmx] Erreur de segmentation

Ceci est arrive (2 fois deja) lors de la compilation du package
debian ocaml, sur une machine bi-celeron (Abit BP-6) avec
debian/unstable, glibc 2.2.2 et un noyau 2.4.1.

Est-ce que le plantage est reproductible? (Se produit toujours,
toujours sur le même fichier source.) Si non, cela sent le problème
hardware: mauvaise mémoire ou surchauffe. (En particulier, les
bi-Celeron sont réputés pour des problèmes de surchauff du "chipset"...)

... meme bug sur athlon 500 :

boot/ocamlrun ./ocamlopt -I stdlib -I utils -I parsing -I typing -I bytecomp
-I asmcomp -I driver -I toplevel -c typing/parmatch.ml
boot/ocamlrun ./ocamlopt -I stdlib -I utils -I parsing -I typing -I bytecomp
-I asmcomp -I driver -I toplevel -c typing/typetexp.ml
boot/ocamlrun ./ocamlopt -I stdlib -I utils -I parsing -I typing -I bytecomp
-I asmcomp -I driver -I toplevel -c typing/typecore.ml
make[1]: *** [typing/typecore.cmx] Segmentation fault
make[1]: Leaving directory `/home/luther/debian/ocaml-3.01-cvs'
make: *** [build-stamp] Error 2
luther@maxime2:/debian/ocaml-3.01-cvs$ dpkg -l libc6
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err:
uppercase=bad)
||/ Name Version Description
+++-==============-==============-============================================
ii libc6 2.2.1-1 GNU C Library: Shared libraries and Timezone
luther@maxime2:
/debian/ocaml-3.01-cvs$ more /proc/version
Linux version 2.2.13 (herbert@gondor) (gcc version 2.95.2 19991103 (Debian
GNU/L
inux)) #1 Sat Nov 20 12:44:19 EST 1999

...

Amicalement,

Sven Luther

@vicuna
Copy link
Author

vicuna commented Feb 27, 2001

Comment author: administrator

Merci d'avoir fait les essais. Ce ne semble pas être lié à la
machine, et les messages de la version "debug" ne me disent rien.
Est-ce que tu pourrais lancer sous gdb?

gdb boot/ocamlrun
run ./ocamlopt -I stdlib -I utils -I parsing -I typing -I bytecomp -I asmcomp -I driver -I toplevel -c typing/typeclass.ml
et quand ça plante:
bt

Merci,

  • Xavier

@vicuna
Copy link
Author

vicuna commented Feb 27, 2001

Comment author: administrator

On Tue, Feb 27, 2001 at 02:24:17PM +0100, Xavier Leroy wrote:

Merci d'avoir fait les essais. Ce ne semble pas être lié à la
machine, et les messages de la version "debug" ne me disent rien.
Est-ce que tu pourrais lancer sous gdb?

gdb boot/ocamlrun
run ./ocamlopt -I stdlib -I utils -I parsing -I typing -I bytecomp -I asmcomp -I driver -I toplevel -c typing/typeclass.ml
et quand ça plante:
bt

huh, ...

je doit avoir le faut ocamlrun, vais essayer a nouveau ...

Début du script sur Tue Feb 27 14:35:28 2001
luther@lambda:/debian/ocaml/cvs/ocaml-3.01-cvs.old$ gdb ����man ocamldebug��������������exit�[K����mutt -y��������[3Pexit����man ocamldebug��������������gdb �[K�����gdb boot/ocamlrun�����������������[1P��[1P��[1P�[1P�
GNU gdb 5.0
Copyright 2000 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 "i686-pc-linux-gnu"...
(no debugging symbols found)...
(gdb) run ./ocamlopt -I stdlib -I utils -I parsing -I typing -I bytecomp -I asmc
omp -I driver -I toplevel -c typing/typeclass.ml
Starting program: /home/luther/debian/ocaml/cvs/ocaml-3.01-cvs.old/boot/ocamlrun ./ocamlopt -I stdlib -I utils -I parsing -I typing -I bytecomp -I asmcomp -I driver -I toplevel -c typing/typeclass.ml
(no debugging symbols found)...(no debugging symbols found)...
Fatal error: cannot find file ./ocamlopt
(no debugging symbols found)...(no debugging symbols found)...
Program exited with code 02.
(gdb) bt
No stack.
(gdb) quit
luther@lambda:
/debian/ocaml/cvs/ocaml-3.01-cvs.old$ exity� �
exit

Script terminé sur Tue Feb 27 14:36:20 2001

@vicuna
Copy link
Author

vicuna commented Feb 27, 2001

Comment author: administrator

On Tue, Feb 27, 2001 at 02:24:17PM +0100, Xavier Leroy wrote:

Merci d'avoir fait les essais. Ce ne semble pas être lié à la
machine, et les messages de la version "debug" ne me disent rien.
Est-ce que tu pourrais lancer sous gdb?

gdb boot/ocamlrun
run ./ocamlopt -I stdlib -I utils -I parsing -I typing -I bytecomp -I asmcomp -I driver -I toplevel -c typing/typeclass.ml
et quand ça plante:
bt

Voila, c'est mieux comme cela, ...

ca plante dans __libc_start_main, donc surement quelque chose liee a
l'utilisation de glibc 2.2.2 ?

Voici le log, dis moi si tu a besoin de plus, ou alors un login sur ma machine
?

Amicalement,

Début du script sur Tue Feb 27 14:38:02 2001
luther@lambda:~/debian/ocaml/cvs/ocaml-3.01-cvs$ gdb boot/ocamlrun
GNU gdb 5.0
Copyright 2000 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 "i686-pc-linux-gnu"...
(gdb) run ./ocamlopt -I stdlib -I utils -I parsing -I typing -I bytecomp -I asmc
omp -I driver -I toplevel -c typing/typeclass.ml
Starting program: /home/luther/debian/ocaml/cvs/ocaml-3.01-cvs/boot/ocamlrun ./ocamlopt -I stdlib -I utils -I parsing -I typing -I bytecomp -I asmcomp -I driver -I toplevel -c typing/typeclass.ml

O'Caml runtime: debug mode

Initial minor heap size: 128k bytes
Initial major heap size: 248k bytes
Initial space overhead: 42%
Initial max overhead: 1000000%
Initial heap increment: 248k bytes
Initial stack limit: 1024k bytes
Starting new major GC cycle

O'Caml runtime: heap check

!<>$<Growing heap to 496k bytes
Growing page table to 330 entries

$<>Starting new major GC cycle

O'Caml runtime: heap check

Growing gray_vals to 16k bytes
!<>!<>$<Growing heap to 744k bytes
Growing page table to 394 entries

$&lt;&gt;$&lt;>Starting new major GC cycle

O'Caml runtime: heap check

!<>!Growing heap to 992k bytes
Growing page table to 458 entries
<>!<>$<>$Growing heap to 1240k bytes
Growing page table to 522 entries
<>$<>$<>Starting new major GC cycle

O'Caml runtime: heap check

!<>!Growing heap to 1488k bytes
Growing page table to 586 entries
<>!<>!<>!<>!<Growing heap to 1736k bytes
Growing page table to 650 entries

$&lt;&gt;$&lt;>$<>$<>$<>$<Growing heap to 1984k bytes
Growing page table to 714 entries
$&lt;&gt;$&lt;>Starting new major GC cycle

O'Caml runtime: heap check

!<>!<>!<Growing heap to 2232k bytes
Growing page table to 778 entries

!<>!<>!<>!<>!<>!<>!<>!<>!<>!<Growing heap to 2480k bytes
Growing page table to 842 entries
!<>!
Program received signal SIGSEGV, Segmentation fault.
interprete (prog=0x401ea008, prog_size=831544) at interp.c:652
652 accu = Field(accu, 1); Next;
(gdb) bt
#0 interprete (prog=0x401ea008, prog_size=831544) at interp.c:652
#1 0x805bf11 in caml_main (argv=0xbffff9ac) at startup.c:382
#2 0x80496e2 in main (argc=20, argv=0xbffff9ac) at main.c:41
#3 0x40096f5c in __libc_start_main () from /lib/libc.so.6
(gdb) quit
The program is running. Exit anyway? (y or n) y
luther@lambda:~/debian/ocaml/cvs/ocaml-3.01-cvs$ exit
exit

Script terminé sur Tue Feb 27 14:38:42 2001

@vicuna
Copy link
Author

vicuna commented Feb 27, 2001

Comment author: administrator

huh, ...
je doit avoir le faut ocamlrun, vais essayer a nouveau ...
Fatal error: cannot find file ./ocamlopt

gdb a dû faire un "cd" automatique dans le répertoire boot/ (celui de

l'exécutable). Essaye "cd .." dans gdb avant "run".

  • Xavier Leroy

@vicuna
Copy link
Author

vicuna commented Feb 27, 2001

Comment author: administrator

On Tue, Feb 27, 2001 at 02:41:35PM +0100, Xavier Leroy wrote:

huh, ...
je doit avoir le faut ocamlrun, vais essayer a nouveau ...
Fatal error: cannot find file ./ocamlopt

gdb a dû faire un "cd" automatique dans le répertoire boot/ (celui de

l'exécutable). Essaye "cd .." dans gdb avant "run".

mmm, ... possible, ...

en tout cas, dans mon deuxieme arbre, celui ou j'avait construit ocamlrund,
cela a marche bien.

Je doit partir a 15h (a peu pres) veut tu un login ssh sur ma machine, pour
faire des tests ?

Amicalement,

Sven Luther

@vicuna
Copy link
Author

vicuna commented Feb 27, 2001

Comment author: administrator

Bon, ça a l'air d'être un problème méchant (structure de donnée
corrompue...) Dans la mesure où le même code marche bien sur plein
d'autres systèmes, cela peut être dû à un bug dans gcc ou la lib C
dans debian-unstable; mais cela peut aussi être un problème de
portabilité dans le source d'OCaml.

Je doit partir a 15h (a peu pres) veut tu un login ssh sur ma machine, pour
faire des tests ?

Très volontiers! Tu peux m'envoyer les infos directement à
Xavier.Leroy@inria.fr (sans copie à caml-bugs, car c'est visible sur
le Web!), de préférence chiffré avec PGP (ma clé:
http://pauillac.inria.fr/~xleroy/pgpkey
)

Encore merci,

  • Xavier Leroy

@vicuna
Copy link
Author

vicuna commented Feb 27, 2001

Comment author: administrator

On Tue, Feb 27, 2001 at 02:56:45PM +0100, Xavier Leroy wrote:

Bon, ça a l'air d'être un problème méchant (structure de donnée
corrompue...) Dans la mesure où le même code marche bien sur plein
d'autres systèmes, cela peut être dû à un bug dans gcc ou la lib C
dans debian-unstable; mais cela peut aussi être un problème de
portabilité dans le source d'OCaml.

Comme cela apparait avec glibc 2.2.2 et glibc 2.2.1, c'est peut-etre un bug
liee a glibc 2.2.x, avec quel glibc testez vous, et sur quel systemes ? dans
les deux cas, gcc 2.95.3 est utiliser.

Je doit partir a 15h (a peu pres) veut tu un login ssh sur ma machine, pour
faire des tests ?

Très volontiers! Tu peux m'envoyer les infos directement à
Xavier.Leroy@inria.fr (sans copie à caml-bugs, car c'est visible sur
le Web!), de préférence chiffré avec PGP (ma clé:
http://pauillac.inria.fr/~xleroy/pgpkey
)

mmm, ...

je vient de creer le compte, je vais t'envoyer les infos crypter, ...

si je reussit a comprendre comment cela marche, ...

Encore merci,

De rien, je suis content d'avoir pus contribuer un peu a avoir un ocaml 3.01
qui marche bien partout, et surtout a ne pas avoir de probleme avec le package
ocaml.

Amicalement,

Sven Luther

@vicuna
Copy link
Author

vicuna commented Mar 5, 2001

Comment author: administrator

Cannot reproduce (yet).

@vicuna vicuna closed this as completed Mar 5, 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