MOD replay in IMP3 freezes OS4

Hi,

I know that IMP3 is not so popular for OS4 users, but still, maybe somebody might help me with my issue.

IMP3 is rock solid as long as I do not play any mods. But when I play mods, I get strange crashes and the system freezes.

The crashes/freezes happens only when the current playback of the mod is finished. I added KPrintf calls to the OS4 ptreplay library, and it seems the crashes happen somewhere around the code that unloads the mod.

The strange thing is that the first crash is neither IMP3 nor the ptreplay/ptplay library. The serial output captures a partial crash in CPUDock_idleTask. Then I see another partial crash that is not connected to any other program, but just some raw code in OS4's kernel.

The crashes are also not conneted to the song playing. I noted what song crashed, and replaying the song multiple times does not trigger another crash.

I have heard that other people do not have any issues with mod playback on OS4. Not sure what is different in their system compared to mine.

Accourding to SysMon I have a Creative Labs Sound Core3D / Recon3D / Z-Series with Harald Kanning's hda.audio 6.11 driver.

Thank you and best regards,
Josef

@FlynnTheAvatar

It does crash eventually, but it can work for hours, before it happens.

I use a modified version of ptplay.library for OS4, with added support for vumeter, maybe that helps, but I do not think IMP3 actually uses that.

No idea, if it’s a async issue, (unloaded, before the vumeter has stopped displaying), or if its caused by different modules, maybe it a playback issue, its hard to say.

you, need to track, what order things is happening, make sure nothing has happened out of order.

also things like non initialized data, can be issue, freeing things that’s already freed, closing unnecessary libraries like dos.library without opening it first, all kind issue can cause crashes over time.

Where it crashes has nothing to do with why it crashes, why it crashes comes from something that should have happened, before or something is not as expected before, the place it crashed, often.

is the pointers and the data valid, at the point of crash.
is the code doing what it should.

@LiveForIt

I added debug messages everywhere, but it did not help track the issue down.

A typical crash looks like this:


Something (IMP3, ptplay.library, ptreplay.library) shrambles the system pretty good.

Maybe somebody spots something. I do not see anything major wrong in ptreplay's source code.

@FlynnTheAvatar

I see you have "ISI" , that’s should be illegal instruction, also you have DSI first..

It has jump into some place where there is no code, perhaps my modified libraries can help after all.

What is list call to a library before it crashes?

ptreplay::_PTSendCommand - WaitPort

Is the port valid? track where its free, and where its allocated.
and make sure, its NULL after being freed. (you don't want to guess.)

is WaitPort implemented, in ptreplay?

@FlynnTheAvatar

Ohhh….

Crashed task: CPUDock_idleTask (0x6A422360)
Crashed process: TwinVNC_OS4 (0x5AC5DAD0)

so when your playing modules random programs start crashing… is that not nice?
you most definitely have some kind of memory corruption issue.

@LiveForIt

Thank you for you help. Having another pair of eyes is very helpful.

ptreplay.library uses IExec->WaitPort, and the port is valid. It will be released in _PTFreeModInternal (ptreplay_private.c). Something crashes before this code is reached. Also, code is using just one instance of the CMD and DIE message. It is also freed in _PTFreeModInternal.

I do not see where in ptreplay source a double free or usage after free should occur.

I never experienced a crash when skipping a module, only when reaches the end. So, ptreplay library might not be the issue here.

I did not check ptplay sources in detail, but it is much easier and uses no messages at all. And it allocs a MemoryPool at start and releases it at the end.

So, there might be a bug in IMP3 itself.

@FlynnTheAvatar

In any case, I assume that AHI, will play sample for a while, using SendIO(), there can be issue where sample is freed, before AHI has completed the playback, but if that causes corruption, I wont not think so. can cause a freeze.

I think it's an AHI bug!

I'm away from my X5000,
running the Apollo V4SA
at the moment and I get
random freeze with
stuttering sound after some time(hours).
Hippoplayer with H0ffmans complete library.


All differnt periods of time,
but feels like a memoryleek.


But it would be quite silly to
find a bug after all this years.

Maybe the hardware is doing something
weird that is at fault?

@khayoz

Hippo player uses a different players, or they are integrated, pretty sure its not opening any libraries, except ahi.

Typical Hippo crashes on Digi Booster modules or scream tracker or some not so common modules, some bugs was found in hippo player, and they should be fixed.

it closes dos.library, that’s not problem if dos.library is in rom, as it count be unloaded, but on AmigaOS4.x it does happen on lib count 0. after a while. that bug is fixed.

there was issue with scope, becouse its has its own thread, it was async bug, after while using vometers, that bug was fixed.

So if I was you, I use the latest version it should be a little more stable.

if you find a bug report the issue to github bug tracker.

One thing I can say about the hippo player module players, is that they do hook into some system interrupts. a crash in there will bring down the system.

@khayoz

Thank you for the suggestion!

But sadly, it is not AHI or the soundcard driver. I disabled all IExec->DoIO calls and the IExec->AbortIO/IExec->WaitIO calls at the end.

IMP3 was going through the mods very, very quickly ;)

After a minute or so the system froze again:


It is not the sound card, I had the same freezes/crashes also with an ESI @Julia.

Of course it might be another hardware failure (memory, gfx card, mainboard, ...). But a software bug is much more likely as the system is very stable when not playing mods with heavy usage.

BTW: TuneNet is still playing internet radio after a crash ;) Not sure why that part of the OS is still running when the UI is not...

@FlynnTheAvatar
I don't know anything about this but according to the crash log it fails in a kernel function when trying to write to some struct pointed to by r5 which in your case is NULL. So I guess it's a NULL pointer dereference error in whatever calls this kernel function. Try using kernel.debug if you don't yet use that to hopefully get some more info on which kernel function this could be and try to find what r5 should contain at that point. You may need to find the beginning of the function in the kernel and disassemble it to see if this is an incoming parameter or something read before the point where it crashes. Attaching a debugger may help, you can go up one level in stack trace and see what it calls which is the beginning of that function and where r5 comes from. But the stack trace does not show any application just libraries and kernel calling each other so this may be something the app passes earlier and cause a crash later when that data is processed.

@FlynnTheAvatar

Quote:
If Intuition or something in the graphics subsystem crashes it can lock up the UI and make it appear as if the entire system is frozen, when in fact other tasks that don't interact with the UI are still running normally.

@msteed

in that case, it is possible to log in using rs232..
if you have opened a shell in AmigaOS.

in user-startup I have:

run <>NIL: newshell AUX:

you log in using putty.

Should also work with USB adapters, but I think its better if you have RS232 on your computer.

Okay, I captured another crash with the debug kernel, but it does not contain any new information (at least not for me). No information about what kernel method crashed:

Since I also use imp3 regularly to chat with my friends, I have observed the same behavior. After running imp3, AmiDock freezes without any error message or GR. After using imp3 for a while, AmiDock can be used again without any problems.

I can also confirm the repeated crashes when playing the imp3 mods, it happens randomly and cannot be clearly reproduced.

Since there are already some crash logs here I will not add anything to my post unless it is wanted.

@FlynnTheAvatar

Thank you for describing the problem here and I hope that we can find a solution together.

@FlynnTheAvatar

The error address in the vicinity of 0xCCCCCCCC in the first DSI in post #14 is an important clue. According to the OS4 Wiki, the debug kernel's MUNGE option sets the link pointers in an entry that's being removed from a list to that address.

Accessing the link pointers after an entry has been removed from a list is a common error that can cause intermittent crashes that are very hard to track down. The MUNGE option sets the pointers to 0xCCCCCCCC (an invalid address) to cause programs that do this to crash more consistently.

It appears that IMP3 suffers from this problem. Perhaps not directly, since the DSI is not in IMP3. But IMP3 may pass the removed entry to some system function (AmiDock, apparently) that then crashes when it tries to access it.

I'm not familiar with IMP3. Does it interact with AmiDock when running? In particular, at around the point where the crash occurs? That would be the place to look for a problem with using entries of some sort that have been removed from a list. In post #3 the debug messages you added suggest that the crash happens somewhere in the vicinity of sending and receiving messages. Messages queued at a port are kept in a list, so that's one place to look.

You might also get more information if you set the debuglevel to something higher than 1.