Opened 7 months ago

Closed 3 months ago

#428 closed bug (fixed)

Odyssey's tab switching sometime cause crash

Reported by: Roman Kargin Owned by: Thore Böckelmann
Priority: normal Milestone: 5.0-2020R1
Component: Title.mui Version: 5.0-2019R4
Severity: minor Keywords:
Cc: Samir Hawamdeh, Hubert Maier OS Platform: AmigaOS4
Blocked By: Blocking:
Release Notes:

Description

While working on some updates for the odyssey, find out that it often may crash when I switch fast-fast between tabs, while they are busy-loading something.

It is not 100% reproducible report, but its enough to open 3 tabs, and in all of them start to load some heavy shit (so to make them busy), and then do fast switch between (at least trying to do).

In most case soon or later it will crash with point out on muimaster.library / groupdispatcher().

I attach the crash log, but probably that one will be not enough, and muimaster.library debug must be used. So can do so if you think it is worth to investigate and what params of muimaster to trace

Thanks!

Attachments (15)

Crashlog_Odyssey_2020-02-02_23-13-56.txt (30.0 KB) - added by Roman Kargin 7 months ago.
muidebug_20200306.zip (1.1 MB) - added by Thore Böckelmann 7 months ago.
nightly builds of muimaster.library and Title.mui including debug symbols
Crashlog_Odyssey_2020-02-04_11-25-33.txt (30.5 KB) - added by Roman Kargin 7 months ago.
debug
title_full_debug.txt (9.1 KB) - added by Roman Kargin 7 months ago.
title full debug
Title_debug.zip (136.5 KB) - added by Thore Böckelmann 7 months ago.
Full debug version of Title.mui, case insensitive parser
title_debug_with_input.txt (23.2 KB) - added by Roman Kargin 7 months ago.
debug with input
master_Title_debug.zip (1.3 MB) - added by Thore Böckelmann 7 months ago.
Full debug versions of muimaster.library and Title.mui
Crashlog_Odyssey_2020-03-14_23-57-06.txt (29.2 KB) - added by Samir Hawamdeh 6 months ago.
stack_trace.jpg (490.4 KB) - added by Samir Hawamdeh 6 months ago.
Crashlog_Odyssey_2020-03-15_16-24-43.txt (44.6 KB) - added by Hubert Maier 6 months ago.
Odyssey crash on trying to open MUI prefs
Crashlog_MUI_2020-03-15_17-38-10.txt (45.0 KB) - added by Hubert Maier 6 months ago.
MUI prefs crash
muidebug_20200618.zip (1.3 MB) - added by Thore Böckelmann 3 months ago.
nightly builds of muimaster.library and Title.mui including debug symbols
Crashlog_Odyssey_2020-06-18_19-40-30.txt (27.6 KB) - added by Samir Hawamdeh 3 months ago.
muidebug_20200619.zip (1.3 MB) - added by Thore Böckelmann 3 months ago.
nightly builds of muimaster.library and Title.mui including debug symbols
Crashlog_Odyssey_2020-06-27_15-29-53.txt (46.8 KB) - added by Hubert Maier 3 months ago.
Crashlog with latest debug files in place (20200619)

Change History (61)

Changed 7 months ago by Roman Kargin

comment:1 Changed 7 months ago by Roman Kargin

Forgot to add, that it all happens on MUI-5.0-2019R4.

Also as I see it crashes on lwz r9,0(r3), and r9 are 0x00000002 and r3 are 0xffffffff, if it point out us on anything :)

comment:2 Changed 7 months ago by Thore Böckelmann

Can you please try the debug version of muimaster.library to reproduce the crash?

Changed 7 months ago by Thore Böckelmann

Attachment: muidebug_20200306.zip added

nightly builds of muimaster.library and Title.mui including debug symbols

comment:3 Changed 7 months ago by Thore Böckelmann

Please try these versions of muimaster.library and Title.mui (must be renamed of course!) to reproduce the crash. The crashlog should then contain real file names and line numbers in the stack trace. I suggest to use a build of Odyssey containing debug symbols as well to get a full stack trace.

comment:4 Changed 7 months ago by Roman Kargin

Currently, rebuild odyssey with -gstabs (take some time), but in meantime crash log with just muimaster and title debug versions

Changed 7 months ago by Roman Kargin

debug

comment:5 Changed 7 months ago by Thore Böckelmann

Ok. That log helps. At least it shows that MUI tries to access a possibly invalid parent object of the Title object (the page group which contains the Title object and the single pages) when it tries to trigger a notification of MUIA_Group_ActivePage.

Can you please check Odyssey's source code if it might be possible that any object (Title object, page objects) are temporarily removed from the surrounding group? Just a guess…

comment:6 Changed 7 months ago by Thore Böckelmann

Please try to reproduce the crash with the supplied debug version of Title.mui. This time it is a full blown debug version. Set ENV:muidebug to "INPUT" to create a debug log containing some information about the input handling of Title class.

Changed 7 months ago by Roman Kargin

Attachment: title_full_debug.txt added

title full debug

comment:7 Changed 7 months ago by Roman Kargin

Ops, that one without "set env:muidebug input", will do another one now

comment:8 Changed 7 months ago by Roman Kargin

Well with setenv muidebug set to input, nothing changes in terms of the crash log. It only adds at top:

Title.mui CheckDebug : Title.mui 21.33 (09.03.2020) [svn r6530] debug session
Title.mui CheckDebug : parsing ENV:muidebug contents 'INPUT'
Title.mui CheckDebug : debug flags 20000000

But crash log fully the same as one I attached a few mins ago

comment:9 Changed 7 months ago by Thore Böckelmann

Sorry, my fault. Use lower case "input" for ENV:muidebug.
I really should make the parser case insensitive…

Changed 7 months ago by Thore Böckelmann

Attachment: Title_debug.zip added

Full debug version of Title.mui, case insensitive parser

comment:10 Changed 7 months ago by Thore Böckelmann

Rebuilt Title.mui with case insensitive parser for ENV:muidebug. Please try to reproduce the crash with this version and ENV:muidebug set to "input" (case doesn't matter anymore).

Changed 7 months ago by Roman Kargin

Attachment: title_debug_with_input.txt added

debug with input

comment:11 Changed 7 months ago by Thore Böckelmann

Unfortunately the log does not reveal any inconsistencies. All parent pointers are the same all the time: 0x625B8540. This the object for which the method is called which eventually causes the crash. The method call is always the same, so there is no reason why it should run perfectly 10 times and finally crash.

All I can suspect is the same as before: Odyssey is trashing memory and hence causes MUI the crash.

You can navigate through the tabs using the keyboard instead of the mouse as well. Just use the cursor keys to switch tabs. I wonder if that kind of navigation causes crashes as well.

Are the any crashes after all tabs have finished loading their content? If not, then MUI is not guilty, because MUI does not know anything about Odyssey's page loading. All it does is handling tab switches.

comment:12 Changed 7 months ago by Roman Kargin

The crash is hard to reproduce as it, so I open 3-4 tabs and trying to load in them sites, and at the same time start to switch between each other. Then at some point, it crashes.

As for key navigation: it seems I do something wrong, but I can't navigate via cursor keys over tabs (because it navigates over page). But I found that holding Amiga key and then pressing ½/3 switch between tabs.

Samo have the same kind of crash when just uniconify window and made it active one time (but that again can be surely trashing of memory). Just strange why in stack trace only mui and nothing else.

comment:13 Changed 7 months ago by Thore Böckelmann

Ok, the ability to navigate via cursor keys depends on the application. These keys are eventually "eaten" by Title class, unless there is any other object which "eats" them before. For the Title demo application it is possible to navigate via cursor keys (left, right, page up, page down). Even Space and Return keys work.

comment:14 Changed 7 months ago by Thore Böckelmann

In 6539:

  • Title.c: cloned some code from muimaster.library for debugging objects. This refs #428.

Changed 7 months ago by Thore Böckelmann

Attachment: master_Title_debug.zip added

Full debug versions of muimaster.library and Title.mui

comment:15 Changed 7 months ago by Thore Böckelmann

Please produce an INPUT log again with these two debug versions. Perhaps the additional debug output reveals some broken class hierarchy…

comment:16 Changed 7 months ago by Samir Hawamdeh

@Roman

To switch tabs in Odyssey —> LAmiga+PageUP/PageDown
Don't know if it was documented or not, me just discovered now :-)

comment:17 Changed 7 months ago by Roman Kargin

@Thore
I tried to reproduce it with the latest ones and can't at the moment. Are those changes you do today inside of those debug versions? I will keep trying to crash.

comment:18 Changed 7 months ago by Thore Böckelmann

Are those changes you do today inside of those debug versions?

Of course. But there have been no real changes to the code, except some more detailed debug output.

comment:19 Changed 7 months ago by Thore Böckelmann

Cc: Samir Hawamdeh added

Has anybody tried the new versions with the slightly enhanced debug output already? I really like to know whether the class hierarchy gets broken at some point. From my point of view that is currently the only possible root of the crash. Although there is nothing that I can do about that, a broken class hierarchy would at least point to trashed memory - probably caused by Odyssey.

comment:20 Changed 7 months ago by Roman Kargin

I still tried with no luck. Let the ticket be open for a while, if nothing will happen anymore, it will only mean that memory-trash issue just shifts somewhere.

comment:21 Changed 7 months ago by Samir Hawamdeh

@Thore

I did not install it yet .. i will do this tomorrow
But this kind of crash is not something one can reproduce easily .. i mean for what i see there is no testcase such do this and that and you will trigger the crash :)

It happen almost casually during navigation, maybe opening a link in a new tab, or just loading a site .. in short be sure that soon or later we will meet it again, just who know when

Let the ticket be open for a while

comment:22 Changed 6 months ago by Roman Kargin

@Thore
Interesting that Raziel reports that once he starts to use your last debug versions, the bug disappears for him as well. So or something was fixed, in title/muimaster, or, things just shifted. I will try again with the last debug version and with previous to that one, to see if I still can reproduce with the previous one, and can't with latest one.

comment:23 Changed 6 months ago by Roman Kargin

@Thore
Tried the last version of odyssey on all component (so tests are fair and not related to odyssey different builds):

  1. CAN reproduce with original title.mui from 2019r4 release archive, and muimaster.library from the same archive
  2. CAN reproduce with original title.mui from 2019r4 release archive, and muimaster.library.debug from ticket named "muidebug_20200306.zip"
  3. CAN'T reproduce with original title.mui from 2019r4 release archive, and very latest muimaster.library.debug from that ticket (from "master_Title_debug.zip" archive)

Can you build the latest version of muimaster.library without debugging now as well, so we can see if bug then arises again or not. At least based on results we will have something to think about.

comment:24 Changed 6 months ago by Thore Böckelmann

Can you build the latest version of muimaster.library without debugging now as well, so we can see if bug then arises again or not. At least based on results we will have something to think about.

This is what the public nightly builds are meant for ;) All relevant changes have been commited and the nightly builds include the changes.

comment:25 in reply to:  24 Changed 6 months ago by Roman Kargin

This is what the public nightly builds are meant for ;) All relevant changes have been committed and the nightly builds include the changes.

Dunno if it expected to be like this, but nightly builds contain debug versions of libs and not release ones. I.e. MUI-5.0-20200313r6541-os4.lha contain muimaster.library of 3.359.823 of size. A version from the last release archive is 890kb of size.

I anyway tried that one and I can again reproduce the bug (and it seems 1:1 the same of size as one from muidebug_20200306.zip attachment).

The only one when I can't reproduce a bug (at least the same easy as with others), is the latest one with additional debugging added (master_Title_debug.zip).

Maybe some sections of code shift somehow in the version with additional debugging, which make the issue disappear.

comment:26 Changed 6 months ago by Thore Böckelmann

Ok, I think there is some misunderstanding of the terms "debug version" and "debug build".

The nightly build archives contain binaries with exactly the same runtime behaviour just like the release binaries. No additional code, no debug output. But additionally they contain debug symbols, which are only of interest in case of a crash. With these additional debug symbols GR is able to print out file names and line numbers in the crashlog instead of just offsets.

A debug version is a very special build with additional debug code (and debug symbols). Of course this additional debug code does affect the runtime behaviour, even if no real debug output is produced due to the flags defined in ENV:muidebug. But there is no different runtime behaviour for the normal code, except the time required for the (optional) debug output. But of course the stack layout may change due to the debug code, which requires temporary buffers for the generated text. And this changed stack layout might hide issues which occur again when the debug code is disabled.

The debug version of muimaster.library is required if for a full class hierarchy in the debug output is desired. Otherwise the normal version is ok as well.

comment:27 Changed 6 months ago by Samir Hawamdeh

Ok, been able to reproduce it in the usual way, just by opening a new tab
Tested on stable MUI 5.0-2019R4 (svn r6515) and latest Odyssey 1.23 r5_beta02

Attached a crashlog and a stacktrace grab

Changed 6 months ago by Samir Hawamdeh

Changed 6 months ago by Samir Hawamdeh

Attachment: stack_trace.jpg added

comment:28 Changed 6 months ago by Roman Kargin

@Samir
That of no help sadly.

As you can see in the last posts, it can be reproduced with everything, but not with the muimaster.library.debug from the last attachment there, which contains additional debug info.

We need to reproduce it with exactly that version from last attachment and with ENV:muidebug set to "input" + crash log taken from serial. Pure crash logs from pure versions are of no use as you can see from previous comments.

comment:29 Changed 6 months ago by Hubert Maier

@Thore

I know i'm completely wrong here, but i didn't want to open a new ticket, see below why.

I was trying to catch that tab crash in Odyssey, but wasn't able to, so i left the debug versions in place and checked out something else.
When i was trying to open MUI prefs from Odyssey and later MUI prefs on it s own, i was getting a crash in dbclassname.
See attached crashlogs.

The reason why i didn't want to open a new item is that this crash is produced with the debug build mentioned here.

Please advise, should i open a new item for this one?
Is this crash to be expected due to the nature of the debug build?
Is there something else interfering?

Thank you

edit: I need to add that opening MUI prefs window does not crash, but switching preferences does.
e.g. click on anything else than the the one MUI prefs is opened in, i.e. switch from Info to System

Last edited 6 months ago by Hubert Maier (previous) (diff)

Changed 6 months ago by Hubert Maier

Odyssey crash on trying to open MUI prefs

Changed 6 months ago by Hubert Maier

MUI prefs crash

comment:30 Changed 6 months ago by Thore Böckelmann

Sorry for the long delay, I got sidetracked and almost forgot about this issue.

Well, I relly cannot be sure whether this new crash might be related to some version mixup.

Tracking down this issue might become quite hard. Without any additional debug code the crash does happen, but as soon as some more code comes into play the crash goes away. Thank you Heisenberg… So this seems to be timing related as well.

Right now I am really out of ideas since no other application than Odyssey causes any problems with tab switching. If there would be a general fault in Title class (or anywhere else in MUI) then even the supplied Title demo should crash as well. You can add lots of tabs there, switch between them, close them again. Just the background web page loading is missing, but that is beyond MUI's scope anyway.

Changed 3 months ago by Thore Böckelmann

Attachment: muidebug_20200618.zip added

nightly builds of muimaster.library and Title.mui including debug symbols

comment:31 Changed 3 months ago by Thore Böckelmann

Just trying to track down this issue once more. Please try to reproduce the crash using the latest debug versions from muidebug_20200618.zip. Also please set ENV:muidebug to "INPUT". It must be possible to grasp a straw here…

Last edited 3 months ago by Thore Böckelmann (previous) (diff)

comment:32 Changed 3 months ago by Samir Hawamdeh

Ok i was able to reproduced something (not tested setting env yet)
Crashlog attached

Changed 3 months ago by Samir Hawamdeh

comment:33 Changed 3 months ago by Thore Böckelmann

In 6570:

  • Title.c: changed a TRUE value to TAG_DONE to terminate a taglist. This refs #428.

comment:34 Changed 3 months ago by Thore Böckelmann

I must have read that line a thousand times already, but today I finally spotted the TRUE instead of TAG_DONE at the end of the SetAttrs() call. That call worked by pure luck for such a long time.

I really hope this was the real cause for this crash.

Changed 3 months ago by Thore Böckelmann

Attachment: muidebug_20200619.zip added

nightly builds of muimaster.library and Title.mui including debug symbols

comment:35 Changed 3 months ago by Samir Hawamdeh

Seems solved, atleast no crashes till now
Waiting for kas1e response then

comment:36 Changed 3 months ago by Thore Böckelmann

Cc: Hubert Maier added
Component: undefinedTitle.mui
Milestone: future release5.0-2020R1
OS Platform: undefinedAmigaOS4
Owner: set to Thore Böckelmann
Priority: undecidednormal
Status: newassigned

Seems solved, atleast no crashes till now

That's great to hear!

Roman and Hubert, what about you?

comment:37 Changed 3 months ago by Thore Böckelmann

Bump! Any further answer?

comment:38 Changed 3 months ago by Roman Kargin

@Thore
Oh sorry, completely miss it all, will check today.

comment:39 Changed 3 months ago by Roman Kargin

@Thore
I tested that muidebug_20200619.zip​ + on top of it muimaster_Popmenu_20200627 : and so far no crashes. But then, its again debug versions, and they didn't crash before too, the only crashed ones non-debug ones.

So to be sure that all allright, i probabaly need to wait for full today's nightly build (because of other bugs in popup which were fixed) , which will not have additional debug symbols.

Last edited 3 months ago by Roman Kargin (previous) (diff)

comment:40 Changed 3 months ago by Thore Böckelmann

A current nightly build can be found here:
r6582 nightly build

Changed 3 months ago by Hubert Maier

Crashlog with latest debug files in place (20200619)

comment:41 Changed 3 months ago by Hubert Maier

@Thore

I still get the same crash as described in comment 29 with the latest debug files (20200619)

I dón t have any debug flags in place, if you need some, plesae advise witch ones.

Sorry for the long delay…work

comment:42 Changed 3 months ago by Thore Böckelmann

@Hubert
But that crash is completely different compared to what this ticket is about. There is no reference to Title class or Group class at all. Only references to other classes used by MUI prefs. For me it looks like a mixup of incompatible versions, i.e. full debug version and debug/nightly build.

Can you reproduce your crash with the r6582 nightly build?

Anyway, that crash is not related to this issue from my point of view.

comment:43 Changed 3 months ago by Hubert Maier

@Thore

That's why I was asking if this crash is related in comment 29, for which I never got an answer and as such assumed it WAS related and did a new test with it today.

I have never been able to get a crash on tab switching while in debug, just like Roman.

I guess you should probably just ignore me…

comment:44 Changed 3 months ago by Thore Böckelmann

@Hubert
If you are able to reproduce the crash with a current nightly build without further mixed versions then please open a separate ticket.

I am quite confident this issue is fixed now and your crash was caused by a bad coi8only.

comment:45 Changed 3 months ago by Roman Kargin

@Thore
With ​r6582 nightly build, I also can't reproduce a crash anymore.

Through, I see that this nightly build contains an unstripped binary with debug symbols, hope when the release version will be released, that will no cause any difference in our crash. As I see our crashes before gone only when we add extra debug output, not when it just contains debug symbols.

In other words, with 100% sure we can be sure when test release binaries. Things may shift in the binaries with debugging symbols again, so seeing it before with that crash need to recheck release versions later.

comment:46 Changed 3 months ago by Thore Böckelmann

Resolution: fixed
Status: assignedclosed

Wrong. Debug symbols do not change the runtime behaviour of a program. In fact they are even ignored when loading the binary into memory. They only come to use in case of a crash. Then the symbols are explicitly loaded by GrimReaper to show additional information like file name and line numbers.

However, debug code does affect the runtime behaviour, because it is additional code which is executed together with the normal code. This code also might have an impact on the stack memory, which was definitely the case here, because the missing TAG_DONE was hidden by the additional code.

Anyway, I am glad this is fixed now.

Note: See TracTickets for help on using tickets.