Author Topic: Requesting final solution  (Read 1234 times)

rst

  • Posts: 309
Requesting final solution
« on: 16 Sep '16 - 12:54 »
Old problem on XMplay, when certain plugins make the media player to crash.



IN fact and in my opinion it is the XMplay weak side, and for that want to request for a final solution, not just remove the plugin. The XMplay shouldnt crash because a plugin, in my opinion.

An the big problem, the notified plugin that produce the crash, is a lie the most cases of times. The problem seems complex, because some plugins affects others. If for example i remove the 'xmp-vgmstream', then the 'xmp-zxtune' isnt causing the crash. ?????????

It is not the only one plugin that cause that problem.

And also dont forget the fact about when we pass 0 Bytes file to the list. Certain plugins crash the whole XMplay. No way.
« Last Edit: 16 Sep '16 - 13:08 by rst »

Ian @ un4seen

  • Administrator
  • Posts: 20389
Re: Requesting final solution
« Reply #1 on: 16 Sep '16 - 13:55 »
It isn't really possible to just ignore a crash, as it could leave things in an unstable state. The crash is passed on to Windows so that a dump file can be generated for more info if needed.

As far as I'm aware, the xmp-vgmstream plugin bug is the only one that affects other plugins (the "(null)" filename in your screenshot suggests it was the culprit in this case). That bug has been fixed in the plugin's source code, but I'm not sure if a new build has been released (the plugin should not be used until then).

rst

  • Posts: 309
Re: Requesting final solution
« Reply #2 on: 16 Sep '16 - 17:12 »
Ian, i am not requesting an ignore crash, but yes to isolate. XMplay in my opinion, cant be compromissed because a plugin. An specially, the given information must be displayed properly, i mean, the real one plugin that it is causing the problem.

piovrauz

  • Posts: 967
Re: Requesting final solution
« Reply #3 on: 17 Sep '16 - 19:38 »
Proposed soluion: have XMPlay NOT LOAD xmp-vgmstream if its version is older than the one that fixes it (but, again, someone would need to actually build the fixed plugin)

rst

  • Posts: 309
Re: Requesting final solution
« Reply #4 on: 18 Sep '16 - 22:39 »
better proposed solution: if a plugin send a crash, then disable it and warn the use, but dont let XMplay to crash.

saga

  • Posts: 2179
Re: Requesting final solution
« Reply #5 on: 19 Sep '16 - 01:02 »
Again, this is not possible. You do not seem to have a clear understanding of what a crash is. When a plugin crashes, it has performed an illegal operation, and as a result of this, the program is likely to be in an inconsistent state (data and program code may have been overwritten with bogus data). Letting the program continue to run in this state is a very bad idea because it can no longer perform correctly. If you're happy, it will just output loud noise on your speakers; if you're unlucky it will wipe your entire music collection from the disk - unlikely, but possible. As a consequence, ignoring a crash will most often just result in another crash a second later. You cannot "not let XMPlay crash" in this situation, it is technically just impossible.
Just believe Ian when he tells you multiple times by now that XMPlay cannot ignore a crash.

The only "sound" way to gracefully handle crashes would be to put plugins into their own sandbox process (so that XMPlay can continue functioning when a plugin process crashed), but this introduces CPU overhead, requires a lot of code to be rewritten and is normally not really needed for such a simple audio player.
« Last Edit: 19 Sep '16 - 01:06 by saga »

piovrauz

  • Posts: 967
Re: Requesting final solution
« Reply #6 on: 19 Sep '16 - 14:29 »
Maybe he meant to warn the user about what plugin crash and disable it for next tme XMPlay is started?
Something like a "blacklisting" after the crash so it doesn't crash again?

guest

  • Guest
Re: Requesting final solution
« Reply #7 on: 20 Sep '16 - 16:18 »
When a program loads a .dll plugin, it becomes a part of the program.
So it's not just plugin crashes, it's the whole program that crashes.

rst

  • Posts: 309
Re: Requesting final solution
« Reply #8 on: 22 Sep '16 - 18:11 »
and the most important, 'warn the user about the correct plugin that caused the problem'. Like i said, the current alert points to other plugins that arent causing the problem.

piovrauz

  • Posts: 967
Re: Requesting final solution
« Reply #9 on: 22 Sep '16 - 21:39 »
As far I know, when a program crashes it's in a "broken" status so how is it supposed to do something right like telling which plugin crashed?

guest

  • Guest
Re: Requesting final solution
« Reply #10 on: 23 Sep '16 - 10:19 »
to rst: again, not possible. The program knows the address of an instruction that crashed, so it can find a name of a plugin that crashed.
But it cannot know a real reson for the crash; it cannot determine which plugin misbehaves.

Ian @ un4seen

  • Administrator
  • Posts: 20389
Re: Requesting final solution
« Reply #11 on: 4 Oct '16 - 13:24 »
Here's an update that should prevent the xmp-vgmstream plugin causing problems:

   www.un4seen.com/stuff/xmplay.exe

It prevents plugins closing file handles that were opened by XMPlay (which is what xmp-vgmstream is doing).

rst

  • Posts: 309
Re: Requesting final solution
« Reply #12 on: 7 Oct '16 - 14:50 »
thx so much Ian, the most important thing is that XMplay inform correctly the user about which plugin cause the problems, that was a problem for me because it reports others.