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...