Am 05.08.2015 um 16:31 schrieb Antonio Scuri:
> Can you list the call stack up to that point?
That's been more tricky than expected.
> IupFlush will not change other IUP calls, but it may trigger system
> events that actually do some IUP calls too. So, if the IUP canvas is being
> destroyed while IupFlush triggered the events, then Yes, it will crash.
I'm seeing a sequence of IupRefresh's followed by IupDestroy's. No
refresh to handles after they've been destroyed.
However the IupFlush is called only every so often. (Normally either
every 150ms or once *all* pending Iup* calls from the application are
processed.)
In practice I've seen up to 4 refresh and destroys until the next
IupFlush was called.
That IupFlush does segfault.
That's something I'd rather love not to have. I'd prefer invalid calls
to be rejected via return code. Or at least the very call fail - even
by a segfault - which is called with invalid parameters. But a
segfault after handful of successfully accepted calls later - that's
hard to debug.
For now I've found a workaround: just insert IupFlush's after every
Iup*whatever call. This does at least not segfault.
But it's nowhere near perfection. I can feel the app being slowed down
now. And it flickers now, intermediately drawing wrong sized controls
over perfect areas just to update them a split second later.
/Jörg
>
> Scuri
>
>
> On Wed, Aug 5, 2015 at 10:58 AM, "Jörg F. Wittenberger" <
> joerg.wittenber...@softeyes.net> wrote:
>
>> What does it mean that the canvas is still valid? (This seems to hint
>> to the point.) I presume it's valid until IupDestroy'ed.
>>
>> This happens to me when I use the back-button in my little app. And
>> only if I'm tripple-clicking it fast enough.
>>
>> The app will create a fresh ScrollBox (a canvas, I gather), fill it with
>> results and push it to display. Then it will proceed to handle the next
>> button push doing the same thing again.
>>
>> Conceivably it could be faster than the update process inside iup.
>>
>> However all those updates are passed down the same queue in sequence.
>> There is only one "green thread", which would ever call IupFlush and
>> {IupDetach+IupUnmap+IupDestroy (in this sequence)}.
>>
>> However if IupFlush would reorder requests... would it?
>>
>> Am 05.08.2015 um 15:42 schrieb Antonio Scuri:
>>> That is a highly used function in IupCanvas. So probably the problem is
>>> not there.
>>>
>>> What did you do before calling IupFlush. Is the canvas still valid
>> during
>>> the flush?
>>>
>>> Best,
>>> Scuri
>>>
>>>
>>> On Wed, Aug 5, 2015 at 5:50 AM, "Jörg F. Wittenberger" <
>>> joerg.wittenber...@softeyes.net> wrote:
>>>
>>>> Hi Antonio,
>>>>
>>>> during IupFlush my program dumped a core like this:
>>>>
>>>> Program terminated with signal SIGSEGV, Segmentation fault.
>>>> #0 0x4097693a in gtkCanvasSetDXAttrib.part.3 () from
>>>> /usr/local/lib/libiup.so
>>>> (gdb) bt
>>>> #0 0x4097693a in gtkCanvasSetDXAttrib.part.3 () from
>>>> /usr/local/lib/libiup.so
>>>> #1 0x00000000 in ?? ()
>>>>
>>>>
>>>> Anything I can do to help debugging that one?
>>>>
>>>> Best
>>>>
>>>> /Jörg
------------------------------------------------------------------------------
_______________________________________________
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users
