- Correctif MinGW-w64 : /mingw64/include/c++/10.3.0/bits/basic-string.h
- &std::vsnprintf vers &vsnprintf
- Redéfinition vsnprintf vers libintl_vsprintf absente de std
- Correctif nntp.cc : strcasestr inexistant sur Windows
- Redéfinition strcasestr vers équivalent WinAPI StrStrIA
- StrStrIA est inclus depuis <shlwapi.h>
- Correctif gui.cc : s_addr renommé en src_addr
- s_addr est défini dans les WinSockets donc incompatibilité de nom.
On Sat, 10 Jul 2021 09:45:02 -0000 (UTC), Marc SCHAEFER wrote:
yamo' wrote:
Ça plante toujours après un certain temps (comme la version « officielle ») mais ça vire au gris au lieu du noir, et l'erreur survient dans libcairo-2.dll... Ça ne m'avance pas beaucoup, surtout que je n'arrive pas Í le faire planter dans GGDB.
Tu n'as peut-être pas les mêmes variables d'environnement.
Une solution sous UNIX (je ne sais pas s'il existe une telle solution sous Microsoft) serait de générer un fichier core. Exemple: :~$ ulimit -c unlimited :~$ cat ^Quit (core dumped) (ici avec la séquence de touche Ctrl-AltGr-) :~$ gdb /bin/cat core GNU gdb (Debian 8.2.1-2+b3) 8.2.1 Program terminated with signal SIGQUIT, Quit. #0 0x00007f6f51660461 in __GI___libc_read (fd=0, buf=0x7f6f51747000, nbytes1072) at ../sysdeps/unix/sysv/linux/read.c:26 26 ../sysdeps/unix/sysv/linux/read.c: No such file or directory. (gdb) where #0 0x00007f6f51660461 in __GI___libc_read (fd=0, buf=0x7f6f51747000, nbytes1072) at ../sysdeps/unix/sysv/linux/read.c:26 #1 0x0000555664f00506 in ?? () #2 0x0000555664efdddb in ?? () #3 0x00007f6f5159a09b in __libc_start_main (main=0x555664efd370, argc=1, argv=0x7ffdad0e7098, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffdad0e7088) at ../csu/libc-start.c:308 #4 0x0000555664efdfaa in ?? () Ainsi le crash serait documenté sans intervention du traçage et des variables d'environnement de gdb, qui sont souvent différentes (je me suis cassé la tête avec ça dans une démo de buffer overflow une fois). Ca peut aussi aider pour la reproductibilité de désactiver certaines protections modernes comme l'ASLR, par exemple sous Linux: echo 0 | sudo tee /proc/sys/kernel/randomize_va_space D'autres recommandations: ajouter les options de sabotage de la libc, utiliser valgrind, etc.
Windows semble refuser de produire des dumps au moment du plantage. En revanche j'ai la sortie suivante (attention copuier-coller). __________________________________ (pan.exe:6400): Gtk-CRITICAL **: 19:28:25.792: gtk_tree_path_compare: assertion 'a != NULL' failed (pan.exe:6400): Gtk-CRITICAL **: 19:28:25.792: gtk_tree_path_compare: assertion 'b != NULL' failed (pan.exe:6400): Gtk-CRITICAL **: 20:07:49.484: gtk_tree_path_compare: assertion 'a != NULL' failed (pan.exe:6400): Gtk-CRITICAL **: 20:07:49.484: gtk_tree_path_compare: assertion 'b != NULL' failed _create_dc_and_bitmap: The parameter is incorrect. (pan.exe:6400): Gtk-CRITICAL **: 20:20:31.020: _gtk_cairo_blur_surface: assertion 'cairo_image_surface_get_format (surface) == CAIRO_FORMAT_A8' failed (pan.exe:6400): Gdk-CRITICAL **: 20:20:31.020: gdk_cairo_set_source_rgba: assertion 'cr != NULL' failed __________________________________ Il faut faire attention Í la date et l'heure ; les quatre premiers avertissements ont eu lieu bien avant le plantage. Je constate donc bien que l'erreur se passe dans "pan.exe" mais je ne vois pas Í quoi le 6400 correspond. Il existe une seule ligne dans le code faisant appel Í la fonction gtk_tree_path_compare et je pense comprendre qu'il y a un pointeur pourri qui arrive lÍ -bas, mais je ne trouve pas d'o͹ viennent les appels vers les deux dernières fonctions, qui sont sans doute internes Í GTK+.
On Sat, 10 Jul 2021 09:45:02 -0000 (UTC), Marc SCHAEFER wrote:
yamo' <user@tld.invalid> wrote:
Ça plante toujours après un certain temps (comme la version «
officielle ») mais ça vire au gris au lieu du noir, et l'erreur
survient dans libcairo-2.dll... Ça ne m'avance pas beaucoup, surtout
que je n'arrive pas Í le faire planter dans GGDB.
Tu n'as peut-être pas les mêmes variables d'environnement.
Une solution sous UNIX (je ne sais pas s'il existe une telle solution
sous Microsoft) serait de générer un fichier core.
schaefer@reliand:~$ gdb /bin/cat core GNU gdb (Debian 8.2.1-2+b3) 8.2.1
Program terminated with signal SIGQUIT, Quit.
#0 0x00007f6f51660461 in __GI___libc_read (fd=0, buf=0x7f6f51747000,
nbytes1072) at ../sysdeps/unix/sysv/linux/read.c:26
26 ../sysdeps/unix/sysv/linux/read.c: No such file or directory.
(gdb) where #0 0x00007f6f51660461 in __GI___libc_read (fd=0,
buf=0x7f6f51747000,
nbytes1072) at ../sysdeps/unix/sysv/linux/read.c:26
#1 0x0000555664f00506 in ?? ()
#2 0x0000555664efdddb in ?? ()
#3 0x00007f6f5159a09b in __libc_start_main (main=0x555664efd370,
argc=1,
argv=0x7ffdad0e7098, init=<optimized out>, fini=<optimized out>,
rtld_fini=<optimized out>, stack_end=0x7ffdad0e7088)
at ../csu/libc-start.c:308
#4 0x0000555664efdfaa in ?? ()
Ainsi le crash serait documenté sans intervention du traçage et des
variables d'environnement de gdb, qui sont souvent différentes (je me
suis cassé la tête avec ça dans une démo de buffer overflow une fois).
Ca peut aussi aider pour la reproductibilité de désactiver certaines
protections modernes comme l'ASLR, par exemple sous Linux:
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
D'autres recommandations: ajouter les options de sabotage de la libc,
utiliser valgrind, etc.
Windows semble refuser de produire des dumps au moment du plantage. En
revanche j'ai la sortie suivante (attention copuier-coller).
__________________________________
(pan.exe:6400): Gtk-CRITICAL **: 19:28:25.792: gtk_tree_path_compare:
assertion 'a != NULL' failed
Il faut faire attention Í la date et l'heure ; les quatre premiers
avertissements ont eu lieu bien avant le plantage. Je constate donc bien
que l'erreur se passe dans "pan.exe" mais je ne vois pas Í quoi le 6400
correspond. Il existe une seule ligne dans le code faisant appel Í la
fonction gtk_tree_path_compare et je pense comprendre qu'il y a un
pointeur pourri qui arrive lÍ -bas, mais je ne trouve pas d'o͹ viennent les
appels vers les deux dernières fonctions, qui sont sans doute internes Í
GTK+.
On Sat, 10 Jul 2021 09:45:02 -0000 (UTC), Marc SCHAEFER wrote:
yamo' wrote:
Ça plante toujours après un certain temps (comme la version « officielle ») mais ça vire au gris au lieu du noir, et l'erreur survient dans libcairo-2.dll... Ça ne m'avance pas beaucoup, surtout que je n'arrive pas Í le faire planter dans GGDB.
Tu n'as peut-être pas les mêmes variables d'environnement.
Une solution sous UNIX (je ne sais pas s'il existe une telle solution sous Microsoft) serait de générer un fichier core. Exemple: :~$ ulimit -c unlimited :~$ cat ^Quit (core dumped) (ici avec la séquence de touche Ctrl-AltGr-) :~$ gdb /bin/cat core GNU gdb (Debian 8.2.1-2+b3) 8.2.1 Program terminated with signal SIGQUIT, Quit. #0 0x00007f6f51660461 in __GI___libc_read (fd=0, buf=0x7f6f51747000, nbytes1072) at ../sysdeps/unix/sysv/linux/read.c:26 26 ../sysdeps/unix/sysv/linux/read.c: No such file or directory. (gdb) where #0 0x00007f6f51660461 in __GI___libc_read (fd=0, buf=0x7f6f51747000, nbytes1072) at ../sysdeps/unix/sysv/linux/read.c:26 #1 0x0000555664f00506 in ?? () #2 0x0000555664efdddb in ?? () #3 0x00007f6f5159a09b in __libc_start_main (main=0x555664efd370, argc=1, argv=0x7ffdad0e7098, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffdad0e7088) at ../csu/libc-start.c:308 #4 0x0000555664efdfaa in ?? () Ainsi le crash serait documenté sans intervention du traçage et des variables d'environnement de gdb, qui sont souvent différentes (je me suis cassé la tête avec ça dans une démo de buffer overflow une fois). Ca peut aussi aider pour la reproductibilité de désactiver certaines protections modernes comme l'ASLR, par exemple sous Linux: echo 0 | sudo tee /proc/sys/kernel/randomize_va_space D'autres recommandations: ajouter les options de sabotage de la libc, utiliser valgrind, etc.
Windows semble refuser de produire des dumps au moment du plantage. En revanche j'ai la sortie suivante (attention copuier-coller). __________________________________ (pan.exe:6400): Gtk-CRITICAL **: 19:28:25.792: gtk_tree_path_compare: assertion 'a != NULL' failed (pan.exe:6400): Gtk-CRITICAL **: 19:28:25.792: gtk_tree_path_compare: assertion 'b != NULL' failed (pan.exe:6400): Gtk-CRITICAL **: 20:07:49.484: gtk_tree_path_compare: assertion 'a != NULL' failed (pan.exe:6400): Gtk-CRITICAL **: 20:07:49.484: gtk_tree_path_compare: assertion 'b != NULL' failed _create_dc_and_bitmap: The parameter is incorrect. (pan.exe:6400): Gtk-CRITICAL **: 20:20:31.020: _gtk_cairo_blur_surface: assertion 'cairo_image_surface_get_format (surface) == CAIRO_FORMAT_A8' failed (pan.exe:6400): Gdk-CRITICAL **: 20:20:31.020: gdk_cairo_set_source_rgba: assertion 'cr != NULL' failed __________________________________ Il faut faire attention Í la date et l'heure ; les quatre premiers avertissements ont eu lieu bien avant le plantage. Je constate donc bien que l'erreur se passe dans "pan.exe" mais je ne vois pas Í quoi le 6400 correspond. Il existe une seule ligne dans le code faisant appel Í la fonction gtk_tree_path_compare et je pense comprendre qu'il y a un pointeur pourri qui arrive lÍ -bas, mais je ne trouve pas d'o͹ viennent les appels vers les deux dernières fonctions, qui sont sans doute internes Í GTK+.
Fox McCloud45
On Sat, 10 Jul 2021 09:45:02 -0000 (UTC), Marc SCHAEFER wrote:
yamo' wrote:
Ça plante toujours après un certain temps (comme la version « officielle ») mais ça vire au gris au lieu du noir, et l'erreur survient dans libcairo-2.dll... Ça ne m'avance pas beaucoup, surtout que je n'arrive pas Í le faire planter dans GGDB.
Tu n'as peut-être pas les mêmes variables d'environnement.
Une solution sous UNIX (je ne sais pas s'il existe une telle solution sous Microsoft) serait de générer un fichier core. Exemple: :~$ ulimit -c unlimited :~$ cat ^Quit (core dumped) (ici avec la séquence de touche Ctrl-AltGr-) :~$ gdb /bin/cat core GNU gdb (Debian 8.2.1-2+b3) 8.2.1 Program terminated with signal SIGQUIT, Quit. #0 0x00007f6f51660461 in __GI___libc_read (fd=0, buf=0x7f6f51747000, nbytes1072) at ../sysdeps/unix/sysv/linux/read.c:26 26 ../sysdeps/unix/sysv/linux/read.c: No such file or directory. (gdb) where #0 0x00007f6f51660461 in __GI___libc_read (fd=0, buf=0x7f6f51747000, nbytes1072) at ../sysdeps/unix/sysv/linux/read.c:26 #1 0x0000555664f00506 in ?? () #2 0x0000555664efdddb in ?? () #3 0x00007f6f5159a09b in __libc_start_main (main=0x555664efd370, argc=1, argv=0x7ffdad0e7098, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffdad0e7088) at ../csu/libc-start.c:308 #4 0x0000555664efdfaa in ?? () Ainsi le crash serait documenté sans intervention du traçage et des variables d'environnement de gdb, qui sont souvent différentes (je me suis cassé la tête avec ça dans une démo de buffer overflow une fois). Ca peut aussi aider pour la reproductibilité de désactiver certaines protections modernes comme l'ASLR, par exemple sous Linux: echo 0 | sudo tee /proc/sys/kernel/randomize_va_space D'autres recommandations: ajouter les options de sabotage de la libc, utiliser valgrind, etc.
Bon, au final après activation des messages de débogage de GTK+ il s'avère que GTK+ n'arrive plus Í afficher quoi que ce soit car "out of memory" avant de planter. Mais je ne vois pas pourquoi GTK+ excède sa mémoire de quelconque manière.
On Sat, 10 Jul 2021 09:45:02 -0000 (UTC), Marc SCHAEFER wrote:
yamo' <user@tld.invalid> wrote:
Ça plante toujours après un certain temps (comme la version «
officielle ») mais ça vire au gris au lieu du noir, et l'erreur
survient dans libcairo-2.dll... Ça ne m'avance pas beaucoup, surtout
que je n'arrive pas Í le faire planter dans GGDB.
Tu n'as peut-être pas les mêmes variables d'environnement.
Une solution sous UNIX (je ne sais pas s'il existe une telle solution
sous Microsoft) serait de générer un fichier core.
schaefer@reliand:~$ gdb /bin/cat core GNU gdb (Debian 8.2.1-2+b3) 8.2.1
Program terminated with signal SIGQUIT, Quit.
#0 0x00007f6f51660461 in __GI___libc_read (fd=0, buf=0x7f6f51747000,
nbytes1072) at ../sysdeps/unix/sysv/linux/read.c:26
26 ../sysdeps/unix/sysv/linux/read.c: No such file or directory.
(gdb) where #0 0x00007f6f51660461 in __GI___libc_read (fd=0,
buf=0x7f6f51747000,
nbytes1072) at ../sysdeps/unix/sysv/linux/read.c:26
#1 0x0000555664f00506 in ?? ()
#2 0x0000555664efdddb in ?? ()
#3 0x00007f6f5159a09b in __libc_start_main (main=0x555664efd370,
argc=1,
argv=0x7ffdad0e7098, init=<optimized out>, fini=<optimized out>,
rtld_fini=<optimized out>, stack_end=0x7ffdad0e7088)
at ../csu/libc-start.c:308
#4 0x0000555664efdfaa in ?? ()
Ainsi le crash serait documenté sans intervention du traçage et des
variables d'environnement de gdb, qui sont souvent différentes (je me
suis cassé la tête avec ça dans une démo de buffer overflow une fois).
Ca peut aussi aider pour la reproductibilité de désactiver certaines
protections modernes comme l'ASLR, par exemple sous Linux:
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
D'autres recommandations: ajouter les options de sabotage de la libc,
utiliser valgrind, etc.
Bon, au final après activation des messages de débogage de GTK+ il s'avère
que GTK+ n'arrive plus Í afficher quoi que ce soit car "out of memory"
avant de planter.
Mais je ne vois pas pourquoi GTK+ excède sa mémoire de quelconque manière.
On Sat, 10 Jul 2021 09:45:02 -0000 (UTC), Marc SCHAEFER wrote:
yamo' wrote:
Ça plante toujours après un certain temps (comme la version « officielle ») mais ça vire au gris au lieu du noir, et l'erreur survient dans libcairo-2.dll... Ça ne m'avance pas beaucoup, surtout que je n'arrive pas Í le faire planter dans GGDB.
Tu n'as peut-être pas les mêmes variables d'environnement.
Une solution sous UNIX (je ne sais pas s'il existe une telle solution sous Microsoft) serait de générer un fichier core. Exemple: :~$ ulimit -c unlimited :~$ cat ^Quit (core dumped) (ici avec la séquence de touche Ctrl-AltGr-) :~$ gdb /bin/cat core GNU gdb (Debian 8.2.1-2+b3) 8.2.1 Program terminated with signal SIGQUIT, Quit. #0 0x00007f6f51660461 in __GI___libc_read (fd=0, buf=0x7f6f51747000, nbytes1072) at ../sysdeps/unix/sysv/linux/read.c:26 26 ../sysdeps/unix/sysv/linux/read.c: No such file or directory. (gdb) where #0 0x00007f6f51660461 in __GI___libc_read (fd=0, buf=0x7f6f51747000, nbytes1072) at ../sysdeps/unix/sysv/linux/read.c:26 #1 0x0000555664f00506 in ?? () #2 0x0000555664efdddb in ?? () #3 0x00007f6f5159a09b in __libc_start_main (main=0x555664efd370, argc=1, argv=0x7ffdad0e7098, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffdad0e7088) at ../csu/libc-start.c:308 #4 0x0000555664efdfaa in ?? () Ainsi le crash serait documenté sans intervention du traçage et des variables d'environnement de gdb, qui sont souvent différentes (je me suis cassé la tête avec ça dans une démo de buffer overflow une fois). Ca peut aussi aider pour la reproductibilité de désactiver certaines protections modernes comme l'ASLR, par exemple sous Linux: echo 0 | sudo tee /proc/sys/kernel/randomize_va_space D'autres recommandations: ajouter les options de sabotage de la libc, utiliser valgrind, etc.
Bon, au final après activation des messages de débogage de GTK+ il s'avère que GTK+ n'arrive plus Í afficher quoi que ce soit car "out of memory" avant de planter. Mais je ne vois pas pourquoi GTK+ excède sa mémoire de quelconque manière.
