openmsx-bugs Mailing List for openMSX

Bugs item #3047889, was opened at 2010-08-18 18:40
Message generated for change (Comment added) made by manuelbi
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=421861&aid=3047889&group_id=38274

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: General/misc
Group: Next release
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Maarten ter Huurne (mthuurne)
Assigned to: Wouter Vermaelen (m9710797)
Summary: CTRL+key in OSD console sends key down event to MSX

Initial Comment:
- let MSX boot to BASIC
- open the OSD console
- press ctrl-q
- observe lots of q's being printed in BASIC


----------------------------------------------------------------------

>Comment By: Manuel Bilderbeek (manuelbi)
Date: 2010-08-23 23:13

Message:
Well, it got fixed... Shouldn't we close this, although the solution isn't
very nice? Maybe reopen a new item to improve the whole design to make a
better solution?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=421861&aid=3047889&group_id=38274

Bugs item #3047889, was opened at 2010-08-18 18:40
Message generated for change (Tracker Item Submitted) made by mthuurne
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=421861&aid=3047889&group_id=38274

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: General/misc
Group: Next release
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Maarten ter Huurne (mthuurne)
Assigned to: Wouter Vermaelen (m9710797)
Summary: CTRL+key in OSD console sends key down event to MSX

Initial Comment:
- let MSX boot to BASIC
- open the OSD console
- press ctrl-q
- observe lots of q's being printed in BASIC


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=421861&aid=3047889&group_id=38274

Bugs item #3045686, was opened at 2010-08-15 23:13
Message generated for change (Settings changed) made by manuelbi
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=421861&aid=3045686&group_id=38274

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: General/misc
Group: None
Status: Open
Resolution: None
Priority: 3
Private: No
Submitted By: Manuel Bilderbeek (manuelbi)
Assigned to: Nobody/Anonymous (nobody)
Summary: Read/write media are opened RW, which can break replay

Initial Comment:
Currently, openMSX opens read/write media RW, even when recording and replaying event logs. This will make it possible to break even random files on your system if someone gives you a prepared replay file to replay. But, it will also break replays in certain cases, because the written data cannot be undone and the state of the media will hence not be the same each time.(There is no known case for this though.) At the moment, openMSX does check if the file ahs been modified and then generates a warning and opens the file read only after all. This covers most security cases and luckily we have no known games that rely on modification of media. But for debugging purposes etc., it may still be a pain.

Ilari on IRC uses a Copy On Write system for his emulator to address this issue. We should implement this in openMSX some time as well.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=421861&aid=3045686&group_id=38274

Bugs item #3035827, was opened at 2010-07-28 08:58
Message generated for change (Comment added) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=421861&aid=3035827&group_id=38274

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 6
Private: No
Submitted By: https://www.google.com/accounts ()
Assigned to: Nobody/Anonymous (nobody)
Summary: openmsx process hangs at exit very often

Initial Comment:
Hi,

After upgrading to openmsx-0.8.0 I've had this problem. Initially I though it only affects testing hardware configurations, but it seems it happens half the time when exiting any instance of openmsx. See my post at OpenMSX forum: http://forum.vampier.net/viewtopic.php?f=5&t=779

The problem is easy to reproduce on my box - just open any OpenMSX session, and exit it. Around half the time, the process just sits there, nothing is output on the console. If I test all the machine configurations, an addition to the testing being painfully slow (taking around 0.5-3s per machine), it will hang at some point of the testing, seemingly randomly, with the hanging process taking 100% of one of the CPU cores. You need to kill the process (via SIGKILL most of the time, as SIGTERM doesn't work), and very often there is an invalid process left for some time even after killing the process.

If you need additional information to debug this, I'll be happy to provide it.

I'm on Gentoo, x86.

Cheers!
 - Ville Aakko

----------------------------------------------------------------------

>Comment By: https://www.google.com/accounts ()
Date: 2010-08-07 14:13

Message:
Hi!

I investigated this further, and noticed this is caused by PulseAudio.
OpenMSX (or SDL?) has compatibility issues with PulseAudio. Killing
PulseAudio and using ALSA directly fixed the issue (I probably used
SDL:ALSA->PulseAudio setup, setting SDL to use PulseAudio directly might
fix the issue, but I don't remember how to do that. There's an environment
variable....)

Why OpenMSX needs to opens the audio device, when --testconfig, is another
matter that could be discussed, of course. But I think this bug report can
be closed?

Cheers!
 - Ville Aakko

----------------------------------------------------------------------

Comment By: Wouter Vermaelen (m9710797)
Date: 2010-07-28 19:21

Message:
Hi,

Thanks for reporting this bug. Unfortunately so far I've no clue what's
going on. And the bug report doesn't contain enough information to start
investigating the problem.

First of all it would be useful to know where it hangs. This info can be
obtained like this:
  - reproduce a hanging openMSX process
  - figure out the process ID  (via 'top' or 'ps')
  - start gdb and attach to the openMSX process    (start 'gdb' from the
command line, on the gdb prompt type 'attach <pid>')
  - then query the backtrace (on the gdb command promt, type 'bt')

This should give a trace of where in the code openMSX is hanging. The
information will be more useful (more descriptive) when the openMSX
executable contains debug symbols. I don't know if that's the case for
Gentoo.

Possibly we need still more information to track down this bug. But this
should already get us started. Like Manuel already said on the openMSX
forum, it might be useful for you to join our IRC channel. Then we can more
quickly (interactively) debug this problem.


Thanks.

Wouter

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=421861&aid=3035827&group_id=38274