Pan 0.147 sur Windows avec GTK3/GMIME3 !

Bonjour,

Vous venez d'envoyer un message de test Í  destination d'Usenet intitulé 'Pan 0.147 sur Windows avec GTK3/GMIME3 !'.
Ce message a bien été propagé.
(Ce robot répond Í  tout message isolé -- pas les réponses -- posté sur fr.test contenant le mot clé 'test' ou 'essai', sauf si le mot clé 'noreply', 'ignore' or '42' apparaÍ®t également.)
Oui je sais, le titre a été changé.

Cordialement,
le robot de fr.test

P.S: en-têtes du message:

Bytes: 1791
Path: ...!3.eu.feeder.erje.net!feeder.erje.net!weretis.net!feeder8.news.weretis.net!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: Fox McCloud45 <foxmccloud45@hotmail.com>
Newsgroups: fr.test
Subject: Pan 0.147 sur Windows avec GTK3/GMIME3 !
Date: Thu, 8 Jul 2021 23:03:14 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 20
Message-id: <sc807i$b2j$1@dont-email.me>
Mime-version: 1.0
Content-type: text/plain; charset=UTF-8
Content-transfer-encoding: 8bit
Injection-date: Thu, 8 Jul 2021 23:03:14 -0000 (UTC)
Injection-info: reader02.eternal-september.org; posting-host="96201c805b49f1030343ef627bdd32d7"; logging-data="11347"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/2hectJjWtsjsLTBqS/o/WoCt6og5ScjI="
User-agent: Pan/0.147 (Sweet Solitude; 3fc114e gitlab.gnome.org/FoxMcCloud45/pan.git)
Cancel-lock: sha1:yWNOskJPFrKx8wmODEqCxcTh5T4Raw_subject: Pan 0.147 sur Windows avec GTK3/GMIME3 !
Raw_from: Fox McCloud45 <foxmccloud45@hotmail.com>
Flat_text: pan 0.147 sur windows avec gtk3/gmime3 !

On Thu, 8 Jul 2021 23:03:14 -0000 (UTC), Fox McCloud45 wrote:

Configuré avec GTK3, GMIME 3, D-Bus, GnuTLS.

Test post PAN

- 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.

- Correctif e-util.cc : Chaͮnes g_locale_from_utf8 invalides
- Remplacement caractère Unicode buggé vers ":"
-
https://www.mail-archive.com/pan-users@nongnu.org/msg10414.html

Croisement des doigts...

Test version Release noreply

On Fri, 9 Jul 2021 17:38:36 -0000 (UTC), Fox McCloud45 wrote:

On Thu, 8 Jul 2021 23:03:14 -0000 (UTC), Fox McCloud45 wrote:

Configuré avec GTK3, GMIME 3, D-Bus, GnuTLS.

Test post PAN

- 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.

- Correctif e-util.cc : Chaͮnes g_locale_from_utf8 invalides
- Remplacement caractère Unicode buggé vers ":"
-
https://www.mail-archive.com/pan-users@nongnu.org/msg10414.html

Croisement des doigts...

Test version Release noreply

Ç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.

Fox McCloud45 a écrit :

Ç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.

On Sat, 10 Jul 2021 07:30:56 -0000 (UTC), yamo' wrote:

Fox McCloud45 a écrit :

Ç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.

À mon avis il y a un pointeur pourri quelque part.

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.

Exemple:

schaefer@reliand:~$ ulimit -c unlimited
schaefer@reliand:~$ cat
^Quit (core dumped)

(ici avec la séquence de touche Ctrl-AltGr-)

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).

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.

Exemple:

schaefer@reliand:~$ ulimit -c unlimited
schaefer@reliand:~$ cat
^Quit (core dumped)

(ici avec la séquence de touche Ctrl-AltGr-)

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.

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.

Exemple:

schaefer@reliand:~$ ulimit -c unlimited schaefer@reliand:~$ cat ^Quit
(core dumped)

(ici avec la séquence de touche Ctrl-AltGr-)

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 peut faire des dumps si, mais je ne sais pas s'ils sont lisibles
par gdb. Je viens d'activer les dumps, j'attends maintenant que Pan plante
de nouveau (sans gdb).

On Sat, 10 Jul 2021 10:11:59 -0000 (UTC), Fox McCloud45 wrote:

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.

Exemple:

schaefer@reliand:~$ ulimit -c unlimited schaefer@reliand:~$ cat ^Quit
(core dumped)

(ici avec la séquence de touche Ctrl-AltGr-)

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 peut faire des dumps si, mais je ne sais pas s'ils sont lisibles
par gdb. Je viens d'activer les dumps, j'attends maintenant que Pan
plante de nouveau (sans gdb).

J'ai toujours pas réussi Í  le refaire planter donc c'est quand même « un
peu plus stable. »

On Sat, 10 Jul 2021 10:47:14 -0000 (UTC), Fox McCloud45 wrote:

On Sat, 10 Jul 2021 10:11:59 -0000 (UTC), Fox McCloud45 wrote:

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.

Exemple:

schaefer@reliand:~$ ulimit -c unlimited schaefer@reliand:~$ cat ^Quit
(core dumped)

(ici avec la séquence de touche Ctrl-AltGr-)

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 peut faire des dumps si, mais je ne sais pas s'ils sont
lisibles par gdb. Je viens d'activer les dumps, j'attends maintenant
que Pan plante de nouveau (sans gdb).

J'ai toujours pas réussi Í  le refaire planter donc c'est quand même « un
peu plus stable. »

Cela dit, j'observe qu'au fur et Í  mesure des bugs d'affichage « pré-
curseurs » se forment ; par exemple le surlignement dans les menus
commence Í  ne plus fonctionner correctement. Je pense donc que le client
va bientÍ´t planter.