Bug#396520: Proposing a debugging method for this bug
Jérôme Marant wrote: Le jeudi 09 novembre 2006 16:22, Attilio Fiandrotti a écrit : this is exactly what i do in order not to regenrate the iso every time i have to pull in something new and should work easily. Sorry if I'm late on this, but I'm not sure if I did it properly. Since I have to boot with the newt interface to run the snippet, I don't get the necessary libraries installed (gdk, directfb and so on). So, I mounted partitions of the system where I built it and ran it from this chroot. I switched VT's while the bar was progressing without any crash. Was it a correct procedure? I think what you did was correct, and i think this also may be a proof of the fact that gtkdfb is not guilty. Jerome, please look at bug #397678: do you see any similarity with the crash that you experienced in g-i ? Thank you very much for testing, it really helped making some light on this issue. cheers Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#396520: Proposing a debugging method for this bug
Le jeudi 09 novembre 2006 16:22, Attilio Fiandrotti a écrit : > this is exactly what i do in order not to regenrate the iso every time i > have to pull in something new and should work easily. Sorry if I'm late on this, but I'm not sure if I did it properly. Since I have to boot with the newt interface to run the snippet, I don't get the necessary libraries installed (gdk, directfb and so on). So, I mounted partitions of the system where I built it and ran it from this chroot. I switched VT's while the bar was progressing without any crash. Was it a correct procedure? -- Jérôme Marant
Bug#396520: Proposing a debugging method for this bug
Sven Luther wrote: On Wed, Nov 08, 2006 at 04:26:59PM +0100, Jérôme Marant wrote: Le mardi 07 novembre 2006 19:01, Attilio Fiandrotti a écrit : Unfortunately, nothing changed. I can try to provide a new strace output, as soon as someone unbreaks rootskel. So far we stated this bug - cannot be reproduced on a regular debian system - does not look like it's related to the way DFB handles VT switching One more test: could you please compile the attached gtk application (which simply runs a progressbar), pull into the d-i, run it and switch VT while the progressbar runs to see if crashes? So, I need to boot the d-i with the newt installer, switch to another VT and run the program, right? BTW, how do you easily add a binary to the d-i? You wget it from somewhere :) this is exactly what i do in order not to regenrate the iso every time i have to pull in something new and should work easily. cheers Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#396520: Proposing a debugging method for this bug
On Wed, Nov 08, 2006 at 04:45:45PM +0100, Sven Luther wrote: On Wed, Nov 08, 2006 at 04:26:59PM +0100, Jérôme Marant wrote: BTW, how do you easily add a binary to the d-i? You wget it from somewhere :) And if you're building a d-i image yourself, you can also change d-i/installer/build/config/common and set "EXTRAFILES" to something like "EXTRAFILES = /usr/bin/strace" which will also add the extra binary (and all libraries that it uses) -- David Härdeman
Bug#396520: Proposing a debugging method for this bug
On Wed, Nov 08, 2006 at 04:26:59PM +0100, Jérôme Marant wrote: > Le mardi 07 novembre 2006 19:01, Attilio Fiandrotti a écrit : > > > > Unfortunately, nothing changed. > > > I can try to provide a new strace output, as soon as someone unbreaks > > > rootskel. > > > > > > > So far we stated this bug > > > > - cannot be reproduced on a regular debian system > > - does not look like it's related to the way DFB handles VT switching > > > > One more test: could you please compile the attached gtk application > > (which simply runs a progressbar), pull into the d-i, run it and switch > > VT while the progressbar runs to see if crashes? > > So, I need to boot the d-i with the newt installer, switch to another > VT and run the program, right? > > BTW, how do you easily add a binary to the d-i? You wget it from somewhere :) Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#396520: Proposing a debugging method for this bug
Le mardi 07 novembre 2006 19:01, Attilio Fiandrotti a écrit : > > Unfortunately, nothing changed. > > I can try to provide a new strace output, as soon as someone unbreaks > > rootskel. > > > > So far we stated this bug > > - cannot be reproduced on a regular debian system > - does not look like it's related to the way DFB handles VT switching > > One more test: could you please compile the attached gtk application > (which simply runs a progressbar), pull into the d-i, run it and switch > VT while the progressbar runs to see if crashes? So, I need to boot the d-i with the newt installer, switch to another VT and run the program, right? BTW, how do you easily add a binary to the d-i? Thanks. -- Jérôme Marant
Bug#396520: Proposing a debugging method for this bug
Le mardi 07 novembre 2006 14:30, Attilio Fiandrotti a écrit : > Jérôme Marant wrote: > > Le lundi 06 novembre 2006 12:55, Attilio Fiandrotti a écrit : > > > > > >>Jerome, if i provide a simple patch for DFB 0.9.25, could you please > >>rebuild the libdirectfb-udeb and see if the crash is fixed? > >>In this case we could backport the fix from DFB 1.0-rc2 to DFB 0.9.25: > >>would this be possible if fixes this chash? > > > > > > Of course. > > hi jerome > > Attached to this mail you will find a patch that moves DFB's 0.9.25.1 > signal handling to different signals than SIGUSR1/2 (during my tests, > those were replaced to signals number 41 and 42 and everything worked > correctly). > > thanks in anticipation for testing. I rebuilt libdirectfb udeb with your patch and re-generated the miniiso. Unfortunately, nothing changed. I can try to provide a new strace output, as soon as someone unbreaks rootskel. -- Jérôme Marant
Bug#396520: Proposing a debugging method for this bug
Jérôme Marant wrote:
Le mardi 07 novembre 2006 14:30, Attilio Fiandrotti a écrit :
Jérôme Marant wrote:
Le lundi 06 novembre 2006 12:55, Attilio Fiandrotti a écrit :
Jerome, if i provide a simple patch for DFB 0.9.25, could you please
rebuild the libdirectfb-udeb and see if the crash is fixed?
In this case we could backport the fix from DFB 1.0-rc2 to DFB 0.9.25:
would this be possible if fixes this chash?
Of course.
hi jerome
Attached to this mail you will find a patch that moves DFB's 0.9.25.1
signal handling to different signals than SIGUSR1/2 (during my tests,
those were replaced to signals number 41 and 42 and everything worked
correctly).
thanks in anticipation for testing.
I rebuilt libdirectfb udeb with your patch and re-generated the miniiso.
Unfortunately, nothing changed.
I can try to provide a new strace output, as soon as someone unbreaks
rootskel.
So far we stated this bug
- cannot be reproduced on a regular debian system
- does not look like it's related to the way DFB handles VT switching
One more test: could you please compile the attached gtk application
(which simply runs a progressbar), pull into the d-i, run it and switch
VT while the progressbar runs to see if crashes?
I was able to reproduce this bug with qemu using today's gtk miniiso,
i'll try to strace the installer with qemu to see if i get something
like your strace log.
cheers
Attilio
Attilio
//gcc gprogressbar_timer2.c -g -o gprogressbar_timer2 `pkg-config --cflags --libs gtk+-directfb-2.0 gthread-2.0`
#include
#include
#include
#include
#include
#include
static GCond *button_cond = NULL; /* Must be initialized somewhere */
static GMutex *button_mutex = NULL; /* Must be initialized somewhere */
GtkWidget *window, *bar, *button, *box, *hbox, *label;
char *label_text;
static gboolean delete_event( GtkWidget *widget,
GdkEvent *event,
gpointer data )
{
g_print ("delete event occurred\n");
return TRUE;
}
static void destroy( GtkWidget *widget,
gpointer data )
{
//gtk_main_quit ();
g_mutex_lock (button_mutex);
g_cond_signal (button_cond);
g_mutex_unlock (button_mutex);
}
void *eventhandler_thread()
{
gdk_threads_enter(); // Protect from gtk main loop which also performs a gtk_entry_set_text.
gtk_main();
gdk_threads_leave();
}
void *updater_thread()
{
int count=0;
gdouble progress = 0;
while(count < 100) {
count = count +1;
progress = progress+0.01;
sprintf(label_text,"Count = %d\n", count);
gdk_threads_enter(); // Protect from gtk main loop which also performs a gtk_entry_set_text.
gtk_progress_bar_set_fraction(GTK_PROGRESS_BAR(bar), progress);
//gtk_label_set_text(GTK_LABEL(label), label_text);
gdk_flush();
gdk_threads_leave();
sleep(1);
}
}
int main(int argc, char **argv)
{
int ret, myint;
pthread_t thread_id;
GThread *Thread1, *Thread2;
GError *err1 = NULL, *err2 = NULL ;
gtk_init (&argc, &argv);
if( !g_thread_supported() )
{
g_thread_init(NULL);
gdk_threads_init(); // Called to initialize internal mutex "gdk_threads_mutex".
printf("g_thread supported\n");
}
else
{
printf("g_thread NOT supported\n");
}
button_cond = g_cond_new ();
button_mutex = g_mutex_new ();
label_text = malloc (200);
window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
gtk_container_set_border_width (GTK_CONTAINER (window), 10);
gtk_widget_set_size_request (window, 700, 300);
g_signal_connect (G_OBJECT (window), "delete_event",
G_CALLBACK (delete_event), NULL);
g_signal_connect (G_OBJECT (window), "destroy",
G_CALLBACK (destroy), NULL);
bar = gtk_progress_bar_new ();
button = gtk_button_new_with_label("Click me to quit");
g_signal_connect_swapped (G_OBJECT (button), "clicked", G_CALLBACK (gtk_widget_destroy), G_OBJECT (window));
label = gtk_label_new("Blah blah Blah blah Blah blah Blah blah Blah blah Blah blah Blah blah Blah blah Blah blah Blah blah Blah blah Blah blah Blah blah Blah ");
gtk_label_set_single_line_mode(label, TRUE);
box = gtk_vbox_new (FALSE, 5);
hbox = gtk_hbox_new (FALSE, 5);
gtk_box_pack_start(GTK_BOX(box), bar, FALSE, FALSE, 5);
gtk_box_pack_start(GTK_BOX(hbox), label, TRUE, TRUE, 5);
gtk_box_pack_start(GTK_BOX(box), hbox, FALSE, FALSE, 5);
gtk_box_pack_start(GTK_BOX(box), button, FALSE, FALSE, 5);
gtk_container_add(GTK_CONTAINER(window), box);
gtk_widget_show_all (window);
if( (Thread1 = g_thread_create((GThreadFunc)updater_thread, NULL, TRUE, &err1)) == NULL)
{
printf("Thread create failed: %s!!\n", err1->message );
g_error_free ( err1 ) ;
}
if( (Thread2 = g_thread_create((GThreadFunc)eventhandler_thread, NULL, TRUE, &err2)) == NULL)
{
printf("Thread create failed: %s!!\n", err2->
Bug#396520: Proposing a debugging method for this bug
Jérôme Marant wrote:
Le lundi 06 novembre 2006 12:55, Attilio Fiandrotti a écrit :
Jerome, if i provide a simple patch for DFB 0.9.25, could you please
rebuild the libdirectfb-udeb and see if the crash is fixed?
In this case we could backport the fix from DFB 1.0-rc2 to DFB 0.9.25:
would this be possible if fixes this chash?
Of course.
hi jerome
Attached to this mail you will find a patch that moves DFB's 0.9.25.1
signal handling to different signals than SIGUSR1/2 (during my tests,
those were replaced to signals number 41 and 42 and everything worked
correctly).
thanks in anticipation for testing.
Attilio
--- systems/fbdev/vt.c.orig 2006-11-07 14:15:56.0 +0100
+++ systems/fbdev/vt.c 2006-11-07 14:16:03.0 +0100
@@ -232,8 +232,8 @@
if (ioctl( dfb_vt->fd, VT_SETMODE, &dfb_vt->vt_mode ) < 0)
D_PERROR( "DirectFB/fbdev/vt: Unable to restore VT mode!!!\n" );
- sigaction( SIGUSR1, &dfb_vt->sig_usr1, NULL );
- sigaction( SIGUSR2, &dfb_vt->sig_usr2, NULL );
+ sigaction( SIG_SWITCH_FROM, &dfb_vt->sig_usr1, NULL );
+ sigaction( SIG_SWITCH_TO, &dfb_vt->sig_usr2, NULL );
direct_thread_cancel( dfb_vt->thread );
direct_thread_join( dfb_vt->thread );
@@ -363,14 +363,14 @@
pthread_cond_wait( &dfb_vt->wait, &dfb_vt->lock );
continue;
- case SIGUSR1:
+ case SIG_SWITCH_FROM:
if (ioctl( dfb_vt->fd, VT_RELDISP,
dfb_core_suspend( NULL ) == DFB_OK ? 1 : 0 ) < 0)
D_PERROR( "DirectFB/fbdev/vt: VT_RELDISP failed\n" );
break;
- case SIGUSR2:
+ case SIG_SWITCH_TO:
dfb_core_resume( NULL );
if (ioctl( dfb_vt->fd, VT_RELDISP, 2 ) < 0)
@@ -458,8 +458,8 @@
sig_tty.sa_handler = vt_switch_handler;
sigemptyset( &sig_tty.sa_mask );
- if (sigaction( SIGUSR1, &sig_tty, &dfb_vt->sig_usr1 ) ||
- sigaction( SIGUSR2, &sig_tty, &dfb_vt->sig_usr2 )) {
+ if (sigaction( SIG_SWITCH_FROM, &sig_tty, &dfb_vt->sig_usr1 ) ||
+ sigaction( SIG_SWITCH_TO, &sig_tty, &dfb_vt->sig_usr2 )) {
D_PERROR( "DirectFB/fbdev/vt: sigaction failed!\n" );
close( dfb_vt->fd );
return DFB_INIT;
@@ -468,14 +468,14 @@
vt.mode = VT_PROCESS;
vt.waitv = 0;
- vt.relsig = SIGUSR1;
- vt.acqsig = SIGUSR2;
+ vt.relsig = SIG_SWITCH_FROM;
+ vt.acqsig = SIG_SWITCH_TO;
if (ioctl( dfb_vt->fd, VT_SETMODE, &vt ) < 0) {
D_PERROR( "DirectFB/fbdev/vt: VT_SETMODE failed!\n" );
- sigaction( SIGUSR1, &dfb_vt->sig_usr1, NULL );
- sigaction( SIGUSR2, &dfb_vt->sig_usr2, NULL );
+ sigaction( SIG_SWITCH_FROM, &dfb_vt->sig_usr1, NULL );
+ sigaction( SIG_SWITCH_TO, &dfb_vt->sig_usr2, NULL );
close( dfb_vt->fd );
Bug#396520: Proposing a debugging method for this bug
Jérôme Marant wrote:
Le lundi 06 novembre 2006 14:51, Attilio Fiandrotti a écrit :
How does it need to be fixed? Won't using different signal fix the issue?
Using different signals should fix up this specific crash, but basing on
this BR [1] by colin watson cdebconf's signal handling mechanism is not
very robus and needs to be fixed.
If you have some time, could you please boot textual and send to
cdebconf SIGUSR1 and SIGUSR2 signals, to see if it crashes?
It crashes on SIGUSR2. It is OK with SIGUSR1.
looking at debconf.c from cdebconf package
main() {
...
signal(SIGINT, sighandler);
signal(SIGTERM, sighandler);
signal(SIGUSR1, sighandler);
...
}
void sighandler(int sig)
{
int status = 1;
if (sig == SIGCHLD)
{
...
}
save();
/*
* SIGUSR1 used to reconfigure the language. Now it
* only saves the database.
*/
if (sig == SIGUSR1)
return;
cleanup();
exit(status);
}
as you can see only SIGUSR1 is catched, SIGUSR2 is not, so i guess
cdebconf was terminated when you sent him SISGUSR2 as a default action
for uncatched signals.
Still, i don't understand why catching SIGUSR1 if no actions are taken
(it's some kind of dummy handler).
I made some experiments with gdb on i386 with pure DFB applications and
DFB uses internally (inter threads signaling) SIGUSR1 to switch from a
DFB VT to another, and SIGUSR2 to switch back to the DFB VT.
The fact that cdebconf does not get killed when SIGUSR2 is issued
internally by DFB makes me think cdebconf does not receive signals sent
by DFB to himself (inter-threads signaling done in DFB).
When cdebconf is run with the GTKDFB frontend, both DFB and cdebconf
compete to catch SIGUSR1, while SIGUSR2 is catched by DFB only.
Because DFB is started after cdebconf, its signal handler overwrites
cdebconf's one: placing a breakpoint on sighandler() and sending SIGUSR1
to cdebconf showed that the breakpoint was never reached by cdebconf and
DFB only complained about SIGUSR1 received outside of a VT switching
operation.
Summarizing, this is what happens when SIGUSR1/2 is sent to the cdbconf
process from the outside (on i386)
*If cdebconf is run with a frontend different from GTK on DFB (signals
catched by cdebconf only)
Sending SIGUSR1 causes no crash, as sisgnal is dummy handled.
Sending SIGUSR2 causes cdebconf quitting as default behaviour for
uncatched signals.
*If cdebconf is run with GTK on DFB frontend (signals catched by DFB
instead of cdebconf)
Sending SIGUSR1 causes DFB to freeze, sending SIGUSR2 later to resume
correctly.
Sending twice in row SIGUSR1 makes DFB it crash.
Sending SIGUSR2 one single time makes DFB crash.
So, on i386 at least, DFB's signal handling mechanism does not seem to
clash with cdebconf's, which simply no longer receives signals from the
outern world.
Note that if some d-i application, for some reason, should send cdebconf
a SIGUSR1 signal when cdebconf is running with the GTKDFB frontend, this
would mean crashing DFB.
We should make sure that no applications send cdebconf SIGUSR1 ever,
unless we patch DFB to catch other signals than SIGUSR1/2.
Moving DFB's VT switching mechanism to other signals should prevent this
potential specific crash anyway.
Still i don't understand why DFB crashs when VT switching is performed,
maybe this crash is not related to VT switching? maybe signal handling
on AMD64 happens totally differently than on i386?
ATM i can only think about replacing SIGUSR1/2 in DFB with other signals
and see if this crash gets fixed: i'll try to produce the patch.
cheers
Attilio
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#396520: Proposing a debugging method for this bug
Le lundi 06 novembre 2006 14:51, Attilio Fiandrotti a écrit : > > How does it need to be fixed? Won't using different signal fix the issue? > > > > Using different signals should fix up this specific crash, but basing on > this BR [1] by colin watson cdebconf's signal handling mechanism is not > very robus and needs to be fixed. > If you have some time, could you please boot textual and send to > cdebconf SIGUSR1 and SIGUSR2 signals, to see if it crashes? It crashes on SIGUSR2. It is OK with SIGUSR1. Regards, -- Jérôme Marant
Bug#396520: Proposing a debugging method for this bug
Jérôme Marant wrote: Le lundi 06 novembre 2006 12:55, Attilio Fiandrotti a écrit : Jerome, if i provide a simple patch for DFB 0.9.25, could you please rebuild the libdirectfb-udeb and see if the crash is fixed? In this case we could backport the fix from DFB 1.0-rc2 to DFB 0.9.25: would this be possible if fixes this chash? Of course. Ok, i'll try to provide a patch ASAP, i'd really like to see this fixed. Using different signals for cdebconf db saving and DFB vt switching is good, but still cdebconf's signal handling mechanism may need to be fixed. How does it need to be fixed? Won't using different signal fix the issue? Using different signals should fix up this specific crash, but basing on this BR [1] by colin watson cdebconf's signal handling mechanism is not very robus and needs to be fixed. If you have some time, could you please boot textual and send to cdebconf SIGUSR1 and SIGUSR2 signals, to see if it crashes? cheers Attilio [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=316484 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#396520: Proposing a debugging method for this bug
Le lundi 06 novembre 2006 12:55, Attilio Fiandrotti a écrit : > Jerome, if i provide a simple patch for DFB 0.9.25, could you please > rebuild the libdirectfb-udeb and see if the crash is fixed? > In this case we could backport the fix from DFB 1.0-rc2 to DFB 0.9.25: > would this be possible if fixes this chash? Of course. > Using different signals for cdebconf db saving and DFB vt switching is > good, but still cdebconf's signal handling mechanism may need to be fixed. How does it need to be fixed? Won't using different signal fix the issue? -- Jérôme Marant
Bug#396520: Proposing a debugging method for this bug
Jérôme Marant wrote: I ran a lot of them and I could switch back and forth from vt1 to vt7. Nothing crashed at all. BTW, Looking at the strace output, the problem could come from signal usage, like you said. Jerome, thanks for testing: the idea i got is that DFB is not responsable for crashes on AMD64, and the crash happens because of the special meaning SIGUSR1/2 have for cdebconf (whose signal handling mechanism seems to be, BTW, buggy). Back at extremadura i talked with Denis Oliver Knopp about how unsafe was using two so popular signals like SIGUSR1/2 for VT switching and this cdebconf-DFB interation does exploit the issue. In DFB 1.0-rc2 DOK used for VT switching less common signals [1]: /* * FIXME: the following looks like a bad hack. * * SIGUNUSED is no longer unused, but is defined for backwards compatibility. * sparc, mips and alpha signal.h however do not define SIGUNUSED. */ #ifdef SIGUNUSED #define SIG_SWITCH_FROM (SIGUNUSED + 10) #define SIG_SWITCH_TO(SIGUNUSED + 11) #else #define SIG_SWITCH_FROM (31 + 10) #define SIG_SWITCH_TO(31 + 11) #endif ... sigaction( SIG_SWITCH_FROM, &dfb_vt->sig_usr1, NULL ); sigaction( SIG_SWITCH_TO, &dfb_vt->sig_usr2, NULL ); ... Jerome, if i provide a simple patch for DFB 0.9.25, could you please rebuild the libdirectfb-udeb and see if the crash is fixed? In this case we could backport the fix from DFB 1.0-rc2 to DFB 0.9.25: would this be possible if fixes this chash? Using different signals for cdebconf db saving and DFB vt switching is good, but still cdebconf's signal handling mechanism may need to be fixed. cheers Attilio [1] http://www.directfb.org/index.php/viewcvs.cgi/DirectFB/systems/fbdev/vt.c.diff?r1=1.5&r2=1.6 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#396520: Proposing a debugging method for this bug
Le mercredi 01 novembre 2006 12:02, Attilio Fiandrotti a écrit : > Hi Jerome Hello, Sorry for the late reply, I've been away for few days. > First, thank you for spending time working on the crash at VT switch on > AMD64: fixing this bug is really important for the g-i project. You're welcome. I'm pleased if I can help. > I've just cloned your original BR as bug 396520 [1] to separate from the > french keyboard issue, retitled it, assigned to the directfb package and > merged with one by davide. Thanks. > I've cc'ed d-boot this time, but feel free to drop them in future replies. ... > While an application is running, please switch to vt1 (ctrl-alt-f1) and > then back to vt7 to see if you can crash your AMD64 system with a pure > DirectFB (no gtk) application. What kind of crash are you expecting? Are you expecting the whole system to be down? > In the case you should succeed in crashing the application and the > console should become unresonding, you can connect from ssh and issue a > "chvt 7" to get back to X. I ran a lot of them and I could switch back and forth from vt1 to vt7. Nothing crashed at all. BTW, Looking at the strace output, the problem could come from signal usage, like you said. I hope this helps. Regards, -- Jérôme Marant
Bug#396520: Proposing a debugging method for this bug
Hi Jerome First, thank you for spending time working on the crash at VT switch on AMD64: fixing this bug is really important for the g-i project. I've just cloned your original BR as bug 396520 [1] to separate from the french keyboard issue, retitled it, assigned to the directfb package and merged with one by davide. I've cc'ed d-boot this time, but feel free to drop them in future replies. I've looked at you strace log and i think the best way to proceed is to check wether the crash can be reproduced or not also on a regular Debian system, where debugging is easier due to availability of gdb etc. So, i'm now asking you to install the libdirectfb-0.9-25 package on your regular debian system: this will allow you to run DFB applications from it (you'll need to enable framebuffer support at boot time by passing "video=vesa vga=788" to the kernel). Now, please compile and install Directfb examples [2] on your system and run each df_* application in turn. While an application is running, please switch to vt1 (ctrl-alt-f1) and then back to vt7 to see if you can crash your AMD64 system with a pure DirectFB (no gtk) application. In the case you should succeed in crashing the application and the console should become unresonding, you can connect from ssh and issue a "chvt 7" to get back to X. cheers Attilio [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=396520 [2] http://www.directfb.org/downloads/Extras/DirectFB-examples-0.9.25.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
