| 2007-03-22 21:49:33 |
Jonathan Jesse |
bug |
|
|
added bug |
| 2007-03-22 21:49:33 |
Jonathan Jesse |
bug |
|
|
added attachment 'CoreDump.gz' (CoreDump.gz) |
| 2007-03-22 21:49:33 |
Jonathan Jesse |
bug |
|
|
added attachment 'Dependencies.txt' (Dependencies.txt) |
| 2007-03-22 21:49:33 |
Jonathan Jesse |
bug |
|
|
added attachment 'Disassembly.txt' (Disassembly.txt) |
| 2007-03-22 21:49:33 |
Jonathan Jesse |
bug |
|
|
added attachment 'ProcMaps.txt' (ProcMaps.txt) |
| 2007-03-22 21:49:33 |
Jonathan Jesse |
bug |
|
|
added attachment 'ProcStatus.txt' (ProcStatus.txt) |
| 2007-03-22 21:49:33 |
Jonathan Jesse |
bug |
|
|
added attachment 'Registers.txt' (Registers.txt) |
| 2007-03-23 02:46:25 |
Brian Murray |
usplash: importance |
Undecided |
Medium |
|
| 2007-03-23 02:46:25 |
Brian Murray |
usplash: statusexplanation |
|
|
|
| 2007-03-23 08:10:34 |
Apport retracing service |
bug |
|
|
added attachment '<fdopen>' (Stacktrace.txt (retraced)) |
| 2007-03-23 08:10:35 |
Apport retracing service |
bug |
|
|
added attachment '<fdopen>' (ThreadStacktrace.txt (retraced)) |
| 2007-03-23 13:19:59 |
Paul Sladen |
title |
[apport] usplash crashed with signal 5 |
[apport] usplash crashed with SIGTRAP at vesa_setmode->LRMI_int->run_vm86 |
|
| 2007-03-23 15:26:10 |
Paul Sladen |
apport: status |
Unconfirmed |
Confirmed |
|
| 2007-03-23 15:26:10 |
Paul Sladen |
apport: statusexplanation |
|
<mjg59> Crashing in BIOS code? Turns out to be hard to fix.
<sladen> mjg59: can it be hooked, caught and just "failed" rather than leading to a crash?
<mjg59> No
<mjg59> Eh.
<mjg59> You could have a sigsegv handler.
<mjg59> But that is clearly not the right answer
<sladen> vesa_setmode() could catch SIGTRAP before lrmi is called and cleanly exit on failure/trap
<mjg59> I'm not sure how this is preferable
<mjg59> The code either crashes or it doesn't
<sladen> it's the equivalent of try { setmode() } except { printf("failed"); }
<mjg59> sladen: The code tried to write to memory it didn't own. It really should crash.
<sladen> rather than just dying.---in which case apport catches the crash and will want to report it
<mjg59> The right fix is to tell apport to ignore it, not to pretend we're not crashing when we are
<sladen> which is pointless if there's nothing to be done about it
<pitti> mjg59: you can actually do so now in 0.7
<mjg59> pitti: Score
|
|
| 2007-03-23 15:27:08 |
Paul Sladen |
title |
[apport] usplash crashed with SIGTRAP at vesa_setmode->LRMI_int->run_vm86 |
have apport ignore usplash BIOS code crashes (SIGTRAP within vesa_setmode->LRMI_int->run_vm86) |
|
| 2007-03-23 15:28:24 |
Paul Sladen |
title |
have apport ignore usplash BIOS code crashes (SIGTRAP within vesa_setmode->LRMI_int->run_vm86) |
ship apport ignore hook for usplash BIOS code crashes (SIGTRAP within vesa_setmode->LRMI_int->run_vm86) |
|
| 2007-03-23 15:28:45 |
Paul Sladen |
apport: status |
Confirmed |
Rejected |
|
| 2007-03-23 15:28:45 |
Paul Sladen |
apport: statusexplanation |
<mjg59> Crashing in BIOS code? Turns out to be hard to fix.
<sladen> mjg59: can it be hooked, caught and just "failed" rather than leading to a crash?
<mjg59> No
<mjg59> Eh.
<mjg59> You could have a sigsegv handler.
<mjg59> But that is clearly not the right answer
<sladen> vesa_setmode() could catch SIGTRAP before lrmi is called and cleanly exit on failure/trap
<mjg59> I'm not sure how this is preferable
<mjg59> The code either crashes or it doesn't
<sladen> it's the equivalent of try { setmode() } except { printf("failed"); }
<mjg59> sladen: The code tried to write to memory it didn't own. It really should crash.
<sladen> rather than just dying.---in which case apport catches the crash and will want to report it
<mjg59> The right fix is to tell apport to ignore it, not to pretend we're not crashing when we are
<sladen> which is pointless if there's nothing to be done about it
<pitti> mjg59: you can actually do so now in 0.7
<mjg59> pitti: Score
|
|
|
| 2007-03-23 15:31:09 |
Paul Sladen |
usplash: status |
Unconfirmed |
Confirmed |
|
| 2007-03-23 15:31:09 |
Paul Sladen |
usplash: statusexplanation |
|
<pitti> sladen: well, usplash can ship a package hook which sets a particular field
<pitti> sladen: that package hook can examine the current crash report and decide wehther or not to ignore it
|
|
| 2007-03-23 17:22:54 |
Paul Sladen |
usplash: statusexplanation |
<pitti> sladen: well, usplash can ship a package hook which sets a particular field
<pitti> sladen: that package hook can examine the current crash report and decide wehther or not to ignore it
|
Target to Feisty release so we don't get tonnes of bug reports from broken machines. |
|
| 2007-03-30 12:06:36 |
Tollef Fog Heen |
usplash: assignee |
|
pitti |
|
| 2007-03-30 12:06:36 |
Tollef Fog Heen |
usplash: statusexplanation |
Target to Feisty release so we don't get tonnes of bug reports from broken machines. |
|
|
| 2007-03-30 12:08:49 |
Martin Pitt |
usplash: status |
Confirmed |
In Progress |
|
| 2007-03-30 12:08:49 |
Martin Pitt |
usplash: statusexplanation |
|
Matthew, Paul, I'm fine with writing the actual apport hook. Can you please describe exactly when it should be supressed? It should both match the nonsymbolic trace below and the attached apport retrace (which does not mention libx86.so.1 any more for some reason). |
|
| 2007-04-02 13:12:40 |
Martin Pitt |
usplash: status |
In Progress |
Fix Released |
|
| 2007-04-02 13:12:40 |
Martin Pitt |
usplash: statusexplanation |
Matthew, Paul, I'm fine with writing the actual apport hook. Can you please describe exactly when it should be supressed? It should both match the nonsymbolic trace below and the attached apport retrace (which does not mention libx86.so.1 any more for some reason). |
usplash (0.4-44) feisty; urgency=low
.
[ Colin Watson ]
* Add XS-Vcs-Bzr field to debian/control.
.
[ Martin Pitt ]
* add debian/usplash.py: Apport package hook to check whether a crash
happened in run_vm86(), which means a crash in the BIOS. We do not want
crash reports about those, because they are useless. (LP: #94911)
* debian/usplash.install: Install that hook into
/usr/share/apport/package-hooks/.
|
|
