Qt-interest Archive, March 2007
signals/slots queue/not queud any limit?
Message 1 in thread
Hi,
my application uses many threads and signal slots/ mechanism between
them. As this application shows images from several cameras there is a
lot of signal exchanged between all the threads. It seems to work
correctly for a long time if I let it live its live but sometimes (not
very often actually) when I push a button (and a signal is emitted) the
application crashes. So it seems that the segfault may be caused by the
emission of the signal. My questions are : is there any limit to the
number of signals queud in the main Thread ( emitted from other
threads). Is it possible that the signal emitted from the main thread
(which is not queued but directly calls the slot in the main thread)
somehow interfere with the queued signals and causes the segfault? Do
you think I should also queue the signals and not use the direct
connection??
Thanks
--
[ signature omitted ]
Message 2 in thread
Hi,
I don't think there's any limit on the number of signals emitted (other
than available memory if they cannot be processed fast enough).
I would suggest running the program in a debugger, or at least getting a
stack trace from the core file. The error may be elsewhere.
--
[ signature omitted ]
Message 3 in thread
On 12.03.07 20:18:25, Elise Taillant wrote:
> my application uses many threads and signal slots/ mechanism between them. As
> this application shows images from several cameras there is a lot of signal
> exchanged between all the threads. It seems to work correctly for a long time
> if I let it live its live but sometimes (not very often actually) when I push a
> button (and a signal is emitted) the application crashes. So it seems that the
> segfault may be caused by the emission of the signal. My questions are : is
> there any limit to the number of signals queud in the main Thread ( emitted
> from other threads). Is it possible that the signal emitted from the main
> thread (which is not queued but directly calls the slot in the main thread)
> somehow interfere with the queued signals and causes the segfault? Do you think
> I should also queue the signals and not use the direct connection??
I'm not aware of any limits, of course queued signals means a lot of
events for the Qt event queue. Anyway, before you should try stuff based
on guessing you shoul get a backtrace to see where exactly your
application crashes and eventually post it here.
Andreas
--
[ signature omitted ]
Message 4 in thread
For these who are interested, after some days of investigation (and
almost inactivating all the code) I found nothing, then I changed to
Qt4.2.3 and it works, it was the bug fixed in this new release :
"Fixed crashes in threaded programs when Qt uses the Glib main loop."
I'm so relieved!
Elise
Andreas Pakulat wrote:
> On 12.03.07 20:18:25, Elise Taillant wrote:
>
>> my application uses many threads and signal slots/ mechanism between them. As
>> this application shows images from several cameras there is a lot of signal
>> exchanged between all the threads. It seems to work correctly for a long time
>> if I let it live its live but sometimes (not very often actually) when I push a
>> button (and a signal is emitted) the application crashes. So it seems that the
>> segfault may be caused by the emission of the signal. My questions are : is
>> there any limit to the number of signals queud in the main Thread ( emitted
>> from other threads). Is it possible that the signal emitted from the main
>> thread (which is not queued but directly calls the slot in the main thread)
>> somehow interfere with the queued signals and causes the segfault? Do you think
>> I should also queue the signals and not use the direct connection??
>>
>
> I'm not aware of any limits, of course queued signals means a lot of
> events for the Qt event queue. Anyway, before you should try stuff based
> on guessing you shoul get a backtrace to see where exactly your
> application crashes and eventually post it here.
>
> Andreas
>
>
--
[ signature omitted ]
