1 |
Malheureusement ça n'a pas suffit. J'ai réessayé audacious, et il |
2 |
plante toujours. J'ai refait un memtest et il ne trouve rien. Je me |
3 |
demande bien d'ou cela peut venir... |
4 |
|
5 |
Le 05/03/07, Benjamin Graf<bdgraf@×××××.com> a écrit : |
6 |
> Merci pour la réponse ! |
7 |
> memtest86+ n'a apparement rien trouvé. Par contre revdep-rebuild a |
8 |
> recompilé 8 ebuilds. |
9 |
> Si jamais, chez moi j'ai du retirer l'option ask (-a) avec |
10 |
> revdep-rebuild pour que ça fonctionne. |
11 |
> J'espère que ca va suffire ! |
12 |
> |
13 |
> Le 05/03/07, Arofarn<arofarn@××××.fr> a écrit : |
14 |
> > Le Mon, 5 Mar 2007 16:18:53 +0100, |
15 |
> > "Benjamin Graf" <bdgraf@×××××.com> a écrit : |
16 |
> > |
17 |
> > > Bonjour, |
18 |
> > > certaines applications (surtout audacious, scite et inkscape) plantent |
19 |
> > > "comme par magie" après un certain temps d'utilisation (audacious |
20 |
> > > c'est environ après 45min, les autres c'est plus rare). La durée de |
21 |
> > > "non-plantage" varie, je ne sais pas en fonction de quoi. |
22 |
> > > |
23 |
> > > Par exemple, en lançant audacious à partir d'un xterm, je reçois ce |
24 |
> > > texte lors du plantage : |
25 |
> > > |
26 |
> > > The program 'audacious' received an X Window System error. |
27 |
> > > This probably reflects a bug in the program. |
28 |
> > > The error was 'BadRequest (invalid request code or no such |
29 |
> > > operation)'. (Details: serial 8512022 error_code 1 request_code 0 |
30 |
> > > minor_code 0) (Note to programmers: normally, X errors are reported |
31 |
> > > asynchronously; that is, you will receive the error a while after |
32 |
> > > causing it. To debug your program, run it with the --sync command line |
33 |
> > > option to change this behavior. You can then get a meaningful |
34 |
> > > backtrace from your debugger if you break on the gdk_x_error() |
35 |
> > > function.) |
36 |
> > > |
37 |
> > > J'ai déjà essayé de ré-emerger audacious, gtk et xorg mais le problème |
38 |
> > > persiste. Le problème est également indépendant du window manager |
39 |
> > > (j'ai essayé avec fvwm, e17 et wmii). |
40 |
> > > |
41 |
> > > Quelqu'un aurait-il une piste ? |
42 |
> > > |
43 |
> > > Merci ! |
44 |
> > > |
45 |
> > > Benjamin |
46 |
> > |
47 |
> > Salut, |
48 |
> > |
49 |
> > Tu peux essayer "revdep-rebuild" (c'est mon outils de réparation |
50 |
> > préféré avec le marteau). |
51 |
> > Il prend les même argument qu'emerge (en fait à la fin il les passe à |
52 |
> > emerge). |
53 |
> > |
54 |
> > Par exemple: revdep-rebuild -atv |
55 |
> > Va faire la liste de tous les paquet éventuellement cassé et les |
56 |
> > ré-emerger avec les option --ask --tree --verbose pour que tu puisse |
57 |
> > décider si tu veux vraiment le faire avec un maximum d'info. |
58 |
> > |
59 |
> > Sinon, tu peux aussi essayer d'installer memtest86+ pour vérifier ta |
60 |
> > RAM (source fréquente de plantage aléatoire). |
61 |
> > |
62 |
> > |
63 |
> > @+ |
64 |
> > |
65 |
> > Arofarn |
66 |
> > -- |
67 |
> > gentoo-user-fr@g.o mailing list |
68 |
> > |
69 |
> > |
70 |
> |
71 |
-- |
72 |
gentoo-user-fr@g.o mailing list |