Opened 5 weeks ago

Last modified 8 days ago

#428 new bug

Odyssey's tab switching sometime cause crash

Reported by: Roman Kargin Owned by:
Priority: undecided Milestone: future release
Component: undefined Version: 5.0-2019R4
Severity: minor Keywords:
Cc: Samir Hawamdeh OS Platform: undefined
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 (11)

Crashlog_Odyssey_2020-02-02_23-13-56.txt (30.0 KB) - added by Roman Kargin 5 weeks ago.
muidebug_20200306.zip (1.1 MB) - added by Thore Böckelmann 4 weeks 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 4 weeks ago.
debug
title_full_debug.txt (9.1 KB) - added by Roman Kargin 4 weeks ago.
title full debug
Title_debug.zip (136.5 KB) - added by Thore Böckelmann 4 weeks ago.
Full debug version of Title.mui, case insensitive parser
title_debug_with_input.txt (23.2 KB) - added by Roman Kargin 4 weeks ago.
debug with input
master_Title_debug.zip (1.3 MB) - added by Thore Böckelmann 4 weeks 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 3 weeks ago.
stack_trace.jpg (490.4 KB) - added by Samir Hawamdeh 3 weeks ago.
Crashlog_Odyssey_2020-03-15_16-24-43.txt (44.6 KB) - added by Hubert Maier 3 weeks 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 3 weeks ago.
MUI prefs crash

Change History (41)

Changed 5 weeks ago by Roman Kargin

comment:1 Changed 5 weeks 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 5 weeks ago by Thore Böckelmann

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

Changed 4 weeks ago by Thore Böckelmann

Attachment: muidebug_20200306.zip added

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

comment:3 Changed 4 weeks 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 4 weeks 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 4 weeks ago by Roman Kargin

debug

comment:5 Changed 4 weeks 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 4 weeks 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 4 weeks ago by Roman Kargin

Attachment: title_full_debug.txt added

title full debug

comment:7 Changed 4 weeks ago by Roman Kargin

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

comment:8 Changed 4 weeks 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 4 weeks ago by Thore Böckelmann

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

Changed 4 weeks ago by Thore Böckelmann

Attachment: Title_debug.zip added

Full debug version of Title.mui, case insensitive parser

comment:10 Changed 4 weeks 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 4 weeks ago by Roman Kargin

Attachment: title_debug_with_input.txt added

debug with input

comment:11 Changed 4 weeks 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 4 weeks 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 4 weeks 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 4 weeks ago by Thore Böckelmann

In 6539:

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

Changed 4 weeks ago by Thore Böckelmann

Attachment: master_Title_debug.zip added

Full debug versions of muimaster.library and Title.mui

comment:15 Changed 4 weeks 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 4 weeks 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 4 weeks 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 4 weeks 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 4 weeks 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 4 weeks 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 4 weeks 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 3 weeks 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 3 weeks 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 3 weeks 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 3 weeks 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 3 weeks 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 3 weeks 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 3 weeks ago by Samir Hawamdeh

Changed 3 weeks ago by Samir Hawamdeh

Attachment: stack_trace.jpg added

comment:28 Changed 3 weeks 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 3 weeks 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 3 weeks ago by Hubert Maier (previous) (diff)

Changed 3 weeks ago by Hubert Maier

Odyssey crash on trying to open MUI prefs

Changed 3 weeks ago by Hubert Maier

MUI prefs crash

comment:30 Changed 8 days 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.

Note: See TracTickets for help on using tickets.