Bug#373253: [directfb-dev] Cause of g-i crashing on AMD64 at VT switch found
In general your going to run into problems with other software packages if something basic like pthreads cancel is broken. I'd push back on the glibc upstream to get this to work correctly with a glibc install. On 12/4/06, Denis Oliver Kropp [EMAIL PROTECTED] wrote: Frans Pop schrieb: On Monday 04 December 2006 23:55, Denis Oliver Kropp wrote: Attilio Fiandrotti schrieb: IIUC pthread_cancel() is revealing difficult to be replaced: should we proceed adding libgcc1 to d-i, hence leaving you DFB guys all the time you needed to implement an appropriate replacement for that call? I can make quick hackish workarounds for selected drivers now, but if adding the library is still possible, I'd do that. Stated like that I think I prefer my hackish workaround in our build system over your hackish patches :-) Will implement now. You do still intend to remove the pthread_cancel() calls in the not to distant future though? No, it would have been a patch only for you :) -- Best regards, Denis Oliver Kropp .--. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | -- ___ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#373253: [directfb-dev] Cause of g-i crashing on AMD64 at VT switch found
Denis Oliver Kropp wrote: Claudio Ciccani schrieb: Denis Oliver Kropp wrote: Claudio Ciccani schrieb: Denis Oliver Kropp wrote: But pthread_cancel() also terminates the thread at mutex_lock for example which would be bad if a lock is already taken. I'd prefer having well chosen voluntary exit points. That can be avoided by using a similar procedure: pthread_setcancelstate(PTHREAD_CANEL_DISABLE) // // safe calls ... // pthread_setcancelstate(PTHREAD_CANCEL_ENABLE) // process pending cancelations pthread_testcancel() According to me, the problems you are encountering suggest that pthread_cancel() should not be removed. The DI guys prefer to not add a needed extra library (on AMD64), but replace those calls. But an ordinary system have that library installed! We could provide a patch for Debian, but we should not change DirectFB main code accoring to me. That's what I thought :) But your suggestions to guard the code outside the blocking read() by disabling (or better defering) cancelation are good. IIUC pthread_cancel() is revealing difficult to be replaced: should we proceed adding libgcc1 to d-i, hence leaving you DFB guys all the time you needed to implement an appropriate replacement for that call? cheers Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#373253: [directfb-dev] Cause of g-i crashing on AMD64 at VT switch found
On Monday 04 December 2006 23:55, Denis Oliver Kropp wrote: Attilio Fiandrotti schrieb: IIUC pthread_cancel() is revealing difficult to be replaced: should we proceed adding libgcc1 to d-i, hence leaving you DFB guys all the time you needed to implement an appropriate replacement for that call? I can make quick hackish workarounds for selected drivers now, but if adding the library is still possible, I'd do that. Stated like that I think I prefer my hackish workaround in our build system over your hackish patches :-) Will implement now. You do still intend to remove the pthread_cancel() calls in the not to distant future though? Cheers, FJP pgpPS4dpnplLH.pgp Description: PGP signature
Bug#373253: [directfb-dev] Cause of g-i crashing on AMD64 at VT switch found
Attilio Fiandrotti schrieb: IIUC pthread_cancel() is revealing difficult to be replaced: should we proceed adding libgcc1 to d-i, hence leaving you DFB guys all the time you needed to implement an appropriate replacement for that call? I can make quick hackish workarounds for selected drivers now, but if adding the library is still possible, I'd do that. -- Best regards, Denis Oliver Kropp .--. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#373253: [directfb-dev] Cause of g-i crashing on AMD64 at VT switch found
Frans Pop schrieb: On Monday 04 December 2006 23:55, Denis Oliver Kropp wrote: Attilio Fiandrotti schrieb: IIUC pthread_cancel() is revealing difficult to be replaced: should we proceed adding libgcc1 to d-i, hence leaving you DFB guys all the time you needed to implement an appropriate replacement for that call? I can make quick hackish workarounds for selected drivers now, but if adding the library is still possible, I'd do that. Stated like that I think I prefer my hackish workaround in our build system over your hackish patches :-) Will implement now. You do still intend to remove the pthread_cancel() calls in the not to distant future though? No, it would have been a patch only for you :) -- Best regards, Denis Oliver Kropp .--. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#373253: [directfb-dev] Cause of g-i crashing on AMD64 at VT switch found
Hi Denis, On Wednesday 29 November 2006 15:47, Attilio Fiandrotti wrote: Last night, talking with Frans Pop and Kurt Roeckx, it turned out that including correct libraries may be a bit complicated right now, and possibly we could not make it in time for Etch. So, i was asked to investigate about the possibility to remove pthread_cancel() calls from DirectFB code: dok, do you believe that's possible / easy to do? I have just found a relatively simple (but not very clean) hack in the d-i build system that would allow us to include the libgcc_s library in gtk images for amd64 and that does solve the VT switching problems. Proper solutions require changes in non-d-i packages (creating a new udeb) that I doubt is realistic so short before the release of Etch. Especially as gcc one of the already frozen basic toolchain packages. However, as the solution is a hack, I'd prefer to avoid it. As you offered the option to take out the pthread_cancel() calls yourself, I assume that that is a realistic alternative. So I'd like to put the ball in your court. If removing the pthread_cancel() calls from directfb is not too invasive and does not cause any real regressions or coding problems, we'd appreciate if you could provide a patch for that (although I guess that also has packaging implications as it may cause an ABI change, so we need to discuss this with the Debian directfb maintainer too). If you'd prefer to leave the pthread_cancel() calls in, we can implement for Etch the hack that includes the libgcc_s library in g-i images for amd64 and work on a more structural solution after the release. For d-i people... The hack consists of adding a build dependency on libgcc1 for amd64 and adding a line 'EXTRAFILES = /lib/libgcc_s.so.1' (and a comment explaining the ugly hack) in the following files: installer/build/config/amd64/gtk-miniiso.cfg installer/build/config/amd64/cdrom/gtk.cfg installer/build/config/amd64/hd-media/gtk.cfg Cheers, FJP pgpfIZgCMUBP1.pgp Description: PGP signature
Bug#373253: [directfb-dev] Cause of g-i crashing on AMD64 at VT switch found
Denis Oliver Kropp wrote: Attilio Fiandrotti wrote: Hi i recently put my hands on an AMD64 machine, so i had the chance to run the installer from a chroot and i noticed that the crash produces this log libgcc_s.so.1 must be installed for pthread_cancel to work (!) [ 5905:0.000] -- Caught signal 6 (unknown origin) -- libgcc_s.so.1 must be installed for pthread_cancel to work Aborted adding this library (and full libc) to the chroot prevents the crash. Good news! Is it ok to include the library or should the input driver be changed to not use pthread_cancel()? Last night, talking with Frans Pop and Kurt Roeckx, it turned out that including correct libraries may be a bit complicated right now, and possibly we could not make it in time for Etch. So, i was asked to investigate about the possibility to remove pthread_cancel() calls from DirectFB code: dok, do you believe that's possible / easy to do? thanks Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#373253: [directfb-dev] Cause of g-i crashing on AMD64 at VT switch found
Attilio Fiandrotti schrieb: Denis Oliver Kropp wrote: Attilio Fiandrotti wrote: Hi i recently put my hands on an AMD64 machine, so i had the chance to run the installer from a chroot and i noticed that the crash produces this log libgcc_s.so.1 must be installed for pthread_cancel to work (!) [ 5905:0.000] -- Caught signal 6 (unknown origin) -- libgcc_s.so.1 must be installed for pthread_cancel to work Aborted adding this library (and full libc) to the chroot prevents the crash. Good news! Is it ok to include the library or should the input driver be changed to not use pthread_cancel()? Last night, talking with Frans Pop and Kurt Roeckx, it turned out that including correct libraries may be a bit complicated right now, and possibly we could not make it in time for Etch. So, i was asked to investigate about the possibility to remove pthread_cancel() calls from DirectFB code: dok, do you believe that's possible / easy to do? Should be possible with minor effort. pthread_cancel() is evil anyways. -- Best regards, Denis Oliver Kropp .--. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#373253: [directfb-dev] Cause of g-i crashing on AMD64 at VT switch found
Denis Oliver Kropp wrote: Attilio Fiandrotti schrieb: Denis Oliver Kropp wrote: Attilio Fiandrotti wrote: Hi i recently put my hands on an AMD64 machine, so i had the chance to run the installer from a chroot and i noticed that the crash produces this log libgcc_s.so.1 must be installed for pthread_cancel to work (!) [ 5905:0.000] -- Caught signal 6 (unknown origin) -- libgcc_s.so.1 must be installed for pthread_cancel to work Aborted adding this library (and full libc) to the chroot prevents the crash. Good news! Is it ok to include the library or should the input driver be changed to not use pthread_cancel()? Last night, talking with Frans Pop and Kurt Roeckx, it turned out that including correct libraries may be a bit complicated right now, and possibly we could not make it in time for Etch. So, i was asked to investigate about the possibility to remove pthread_cancel() calls from DirectFB code: dok, do you believe that's possible / easy to do? Should be possible with minor effort. pthread_cancel() is evil anyways. Dok, we would really really apreciate if you could provide us ASAP the patch: we're now kind of running out of time as Etch release date gets closer every day. I'll build an experimental ISO image with your patch and ask people to test it to catch possible issues coming from the patch. thanks Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#373253: [directfb-dev] Cause of g-i crashing on AMD64 at VT switch found
Attilio Fiandrotti schrieb: Denis Oliver Kropp wrote: Should be possible with minor effort. pthread_cancel() is evil anyways. Dok, we would really really apreciate if you could provide us ASAP the patch: we're now kind of running out of time as Etch release date gets closer every day. I'll build an experimental ISO image with your patch and ask people to test it to catch possible issues coming from the patch. Working on it now. -- Best regards, Denis Oliver Kropp .--. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#373253: [directfb-dev] Cause of g-i crashing on AMD64 at VT switch found
Denis Oliver Kropp wrote: Attilio Fiandrotti wrote: Hi i recently put my hands on an AMD64 machine, so i had the chance to run the installer from a chroot and i noticed that the crash produces this log libgcc_s.so.1 must be installed for pthread_cancel to work (!) [ 5905:0.000] -- Caught signal 6 (unknown origin) -- libgcc_s.so.1 must be installed for pthread_cancel to work Aborted adding this library (and full libc) to the chroot prevents the crash. Good news! Is it ok to include the library or should the input driver be changed to not use pthread_cancel()? I don't know what's the best option, let's see what d-i people think about this (better keeping directfb-dev cc'ed). cheers attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#373253: [directfb-dev] Cause of g-i crashing on AMD64 at VT switch found
Attilio Fiandrotti wrote: Hi i recently put my hands on an AMD64 machine, so i had the chance to run the installer from a chroot and i noticed that the crash produces this log libgcc_s.so.1 must be installed for pthread_cancel to work (!) [ 5905:0.000] -- Caught signal 6 (unknown origin) -- libgcc_s.so.1 must be installed for pthread_cancel to work Aborted adding this library (and full libc) to the chroot prevents the crash. Good news! Is it ok to include the library or should the input driver be changed to not use pthread_cancel()? -- Best regards, Denis Oliver Kropp .--. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | '--' -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
