[Bug 19861] New: Sonic Heroes crashes on user input (keyboard/mouse)

http://bugs.winehq.org/show_bug.cgi?id=19861

Summary: Sonic Heroes crashes on user input (keyboard/mouse)
           Product: Wine
           Version: 1.1.28
          Platform: PC
               URL: http://www.sega.com
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: -unknown
        AssignedTo: [e-mail]
        ReportedBy: [e-mail]

If you start the game, the game window will be on focus, and the mouse will go
to the center of the window. Any user input, like moving the mouse or pressing
a key will instantly crash the game.

If right after start you quickly move the mouse out the game window, you'll see
the Sega logo. Then the game says: "Press enter to continue...", but you
shouldn't! If you keep the mouse out of the window, then after about two
minutes you press Enter, the game will work.

[Bug 19861] Sonic Heroes crashes on user input (keyboard/mouse)

http://bugs.winehq.org/show_bug.cgi?id=19861

--- Comment #1 from landeel   2009-08-27 17:40:22 ---
Created an attachment (id=23289)
 --> (http://bugs.winehq.org/attachment.cgi?id=23289)
Crash LOG

"Descritor de arquivo inválido" means "invalid file descriptor".

[Bug 19861] Sonic Heroes crashes on user input (keyboard/mouse)

http://bugs.winehq.org/show_bug.cgi?id=19861

--- Comment #2 from landeel   2009-08-27 17:44:02 ---
Created an attachment (id=23290)
 --> (http://bugs.winehq.org/attachment.cgi?id=23290)
output LOG using the trick to avoid the crash

[Bug 19861] Sonic Heroes crashes on user input (keyboard/mouse)

http://bugs.winehq.org/show_bug.cgi?id=19861

Peter Dons Tychsen  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #3 from Peter Dons Tychsen   2009-09-01 14:23:37 ---
Seems to be fixed in GIT.
I have tried the demo of the game without seeing this bug at all.
I would think this is fixed.

[Bug 19861] Sonic Heroes crashes on user input (keyboard/mouse)

http://bugs.winehq.org/show_bug.cgi?id=19861

--- Comment #4 from landeel   2009-09-01 15:06:09 ---
I have the retail version here. I'm not sure the bug affects the demo.

[Bug 19861] Sonic Heroes crashes on user input (keyboard/mouse)

http://bugs.winehq.org/show_bug.cgi?id=19861

--- Comment #5 from Peter Dons Tychsen   2009-09-01 15:15:32 ---
Please try the demo and check.

[Bug 19861] Sonic Heroes crashes on user input (keyboard/mouse)

http://bugs.winehq.org/show_bug.cgi?id=19861

--- Comment #6 from landeel   2009-09-01 19:22:53 ---
This bug does not affect the demo. Only the full version is affected.

[Bug 19861] Sonic Heroes crashes on user input (keyboard/mouse)

http://bugs.winehq.org/show_bug.cgi?id=19861

--- Comment #7 from landeel   2009-10-27 09:30:25 ---
Found an easier way to bypass the bug.

Open winecfg and uncheck "Allow directx apps to..." , "Allow the window manager
to decore..." and "Allow the window manager to control..."

Game simply works with this configuration.

[Bug 19861] Sonic Heroes crashes on user input (keyboard/mouse)

http://bugs.winehq.org/show_bug.cgi?id=19861

--- Comment #8 from landeel   2009-12-21 19:31:30 ---
It seems this bug is fixed in 1.1.35
Game doesn't crash for me anymore.

[Bug 19861] Sonic Heroes crashes on user input (keyboard/mouse)

http://bugs.winehq.org/show_bug.cgi?id=19861

Oleksandr Khayrullin  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #9 from Oleksandr Khayrullin   2010-01-28 11:57:10 ---
Wine 1.1.37. The bug still happens.

[Bug 19861] Sonic Heroes crashes on user input (keyboard/mouse)

http://bugs.winehq.org/show_bug.cgi?id=19861

--- Comment #10 from Jeff Zaroyko   2010-01-28 22:13:18 ---
(In reply to comment #9)
> Wine 1.1.37. The bug still happens.

Does it crash for you in 1.1.35?  If it does we can mark this fixed, file a new
bug and run a regression test to work out what changed.

If it does not crash in 1.1.35 for you then this should probably stay open.

[Bug 19861] Sonic Heroes crashes on user input (keyboard/mouse)

http://bugs.winehq.org/show_bug.cgi?id=19861

--- Comment #11 from landeel   2010-01-29 12:40:04 ---
It doesn't crash for me since 1.1.35. Have you tried a clean wine prefix?

[Bug 19861] Sonic Heroes crashes on user input (keyboard/mouse)

http://bugs.winehq.org/show_bug.cgi?id=19861

James Huk  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #12 from James Huk   2010-03-01 04:16:28 ---
This "bug" is related to max opened file limit in some distributions, it also
affects "Sonic Riders" (probably some other games as well - we just don't know
about them). This bug is distro-dependend because on some distributions (Debian
for example) max opened file limit is quite small, while on others it is
larger.
To fix this you need to increase max opened file limit. For Debian - simply put
something like this in /etc/security/limits.conf:

USERNAME hard nofile 655355

(of course, change USERNAME to your user name ;] )

and re-log - this should allow you to play this game just fine.

[Bug 19861] Sonic Heroes crashes on user input (keyboard/mouse)

http://bugs.winehq.org/show_bug.cgi?id=19861

Dan Kegel  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #13 from Dan Kegel   2010-03-02 10:58:50 ---
Maybe we should issue a +winediag error message
the first time an app runs out of file descriptors
if ulimit is low.

[Bug 19861] Sonic Heroes crashes on user input (keyboard/mouse)

http://bugs.winehq.org/show_bug.cgi?id=19861

--- Comment #14 from James Huk   2010-03-02 12:52:37 ---
@Dan Kegel:

That, or simple message in console would be very nice - when I was debugging
this weird issue, I was force to use WINEDEBUG=+all and then search through
millions of messages to finally find out that file limit was reached - running
wine in terminal didn't help much because the error was not displayed there -
and as already stated in here:

http://bugs.winehq.org/show_bug.cgi?id=19860

I think wine should report this error one way or another.

[Bug 19861] Wine should warn when ulimit -n needs raising

http://bugs.winehq.org/show_bug.cgi?id=19861

Dan Kegel  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Target Milestone|---                         |1.2.0
            Summary|Sonic Heroes crashes on     |Wine should warn when
                   |user input (keyboard/mouse) |ulimit -n needs raising
     Ever Confirmed|0                           |1

--- Comment #15 from Dan Kegel   2010-03-02 13:10:37 ---
Affects multiple apps, one-time ERR probably easy to add -> nominating for 1.2

[Bug 19861] Wine should warn when ulimit -n needs raising

http://bugs.winehq.org/show_bug.cgi?id=19861

--- Comment #16 from landeel   2010-03-02 16:35:36 ---
I have changed the file limit to solve another issue. That explains why Sonic
Heroes no longer crashes for me.

[Bug 19861] Wine should warn when ulimit -n needs raising

http://bugs.winehq.org/show_bug.cgi?id=19861

Reco  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

[Bug 19861] Wine should warn when ulimit -n needs raising

http://bugs.winehq.org/show_bug.cgi?id=19861

Octavian Voicu  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #17 from Octavian Voicu   2010-05-18 13:46:38 ---
Patch sent here: http://source.winehq.org/patches/data/61592 (not commited yet
to git, still pending)

I tested it with a low ulimit -n setting and notepad, and the error message was
triggered. It would be interesting if someone tested it with the games that had
problems with this limit (using the default ulimit seting), so we can see if
the error is generated.

[Bug 19861] Wine should warn when ulimit -n needs raising

http://bugs.winehq.org/show_bug.cgi?id=19861

Dmitry Timoshkov  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|1.2.0                       |---
           Severity|normal                      |minor

--- Comment #18 from Dmitry Timoshkov   2010-06-11 04:31:39 ---
Adding a WARN is not a fix. This is not a Wine bug in the first place
that a user's system is broken (i.e. has such a low file limit).

A workaround is simple and obvious.

[Bug 19861] Wine should warn when ulimit -n needs raising

http://bugs.winehq.org/show_bug.cgi?id=19861

--- Comment #19 from Octavian Voicu   2010-06-11 04:41:45 ---
The bug title says "Wine should warn when ulimit -n needs raising", so the fix
for this specific bug is to warn the user.

Problem is, as you can see from comments of users that encountered this bug,
that they didn't know what caused it and how to work around it. As suggested by
Dan, my patch detects the condition, and also suggest increasing nofile limit.

[Bug 19861] Wine should warn when ulimit -n needs raising

http://bugs.winehq.org/show_bug.cgi?id=19861

--- Comment #20 from Dmitry Timoshkov   2010-06-11 04:49:27 ---
(In reply to comment #19)
> The bug title says "Wine should warn when ulimit -n needs raising", so the fix
> for this specific bug is to warn the user.

As you can see in the original report Wine *already* reports correct error
message to the user.

I believe that any other application that uses a lot of file handles would
just silently break without an apparent reason. Wine does a better job.

This bug should be marked as invalid.

[Bug 19861] Wine should warn when ulimit -n needs raising

http://bugs.winehq.org/show_bug.cgi?id=19861

--- Comment #21 from James Huk   2010-06-11 04:54:25 ---
No wine does not report this unless WINEDEBUG=+all is used, and it should warn
about this in the console. The solution is simple ONLY WHEN you know that the
file limit is responsible. So adding a warning in the console is actually a fix
, or at least an indication for the user to what is wrong. Also the severity of
this "bug" is unknown - we know for sure about few apps, but there are others
probably.

[Bug 19861] Wine should warn when ulimit -n needs raising

http://bugs.winehq.org/show_bug.cgi?id=19861

--- Comment #22 from Dmitry Timoshkov   2010-06-11 05:00:24 ---
The bug should be reported to the distro which has such a low file limit.
Adding a warning fixes nothing.

[Bug 19861] Wine should warn when ulimit -n needs raising

http://bugs.winehq.org/show_bug.cgi?id=19861

--- Comment #23 from Austin English   2010-06-11 05:04:20 ---
(In reply to comment #22)
> The bug should be reported to the distro which has such a low file limit.
> Adding a warning fixes nothing.

It does help prevent bugs getting filed in wine's bugzilla that turn out to be
invalid.

[Bug 19861] Wine should warn when ulimit -n needs raising

http://bugs.winehq.org/show_bug.cgi?id=19861

--- Comment #24 from Alexandre Julliard   2010-06-11 05:06:30 ---
(In reply to comment #22)
> The bug should be reported to the distro which has such a low file limit.
> Adding a warning fixes nothing.

That's what the winediag channel is for, to tell users about problems in their
environment that we can't work around.

[Bug 19861] Wine should warn when ulimit -n needs raising

http://bugs.winehq.org/show_bug.cgi?id=19861

--- Comment #25 from James Huk   2010-06-11 05:10:24 ---
> The bug should be reported to the distro which has such a low file limit.
> Adding a warning fixes nothing.

But it tells the user where the problem is and how to fix it. Believe me when I
say this thing is  hard to "debug" for normal users, because this "bug" can
manifest itself in variety of ways. In Sonic Heroes - there is no music and
game crash when you press the button, in sonic Riders you can't press the
button to start the race and there is no intro. At first most of us would
think, that this are two separate bugs in two different wine sections. However
if wine would warn when file limit is reached, we would know instantly what's
wrong.

Besides - this file limit in distributions is not a bug either - this is a
security measure according to some people.

[Bug 19861] Wine should warn when ulimit -n needs raising

http://bugs.winehq.org/show_bug.cgi?id=19861

--- Comment #26 from Octavian Voicu   2010-06-11 05:15:01 ---
(In reply to comment #22)
> The bug should be reported to the distro which has such a low file limit.
> Adding a warning fixes nothing.

As I suggest here [1], a page on the wiki dedicated to packagers would be nice,
to warn about all these issues, and maybe also list some patches/workarounds
that might be interesting for end users.

With the modular /etc/security/limits.d/, the wine package could install its
own limits there (or, for those distros with low nofile limit, add a
wine-nofile-fix package with that file).

Octavian

[1] http://www.winehq.org/pipermail/wine-devel/2010-May/083594.html

[Bug 19861] Wine should warn when ulimit -n needs raising

http://bugs.winehq.org/show_bug.cgi?id=19861

--- Comment #27 from Dmitry Timoshkov   2010-06-11 05:24:11 ---
(In reply to comment #25)
> Besides - this file limit in distributions is not a bug either - this is a
> security measure according to some people.

If breaking applications is a security of some kind - let be it. I just
would like to repeat once again, that's not only Wine who is potentially
affected, any application that uses a lot of file handles will break, and
most likely without any message.

[Bug 19861] Wine should warn when ulimit -n needs raising

http://bugs.winehq.org/show_bug.cgi?id=19861

--- Comment #28 from Octavian Voicu   2010-06-11 05:56:44 ---
(In reply to comment #27)
> If breaking applications is a security of some kind - let be it. I just
> would like to repeat once again, that's not only Wine who is potentially
> affected, any application that uses a lot of file handles will break, and
> most likely without any message.

We are trying to provide Windows compatibility, and Windows seems to support
between 512 and 2048 open files. On the other hand, just running notepad opens
70 files:

$ wine notepad &
[1] 10762
$ ls -l /proc/`pidof wineserver`/fd | wc -l
70

But Windows' limit is per-application. In Wine's case all open files go through
wineserver, so running more applications means more open files. That's why Wine
needs more open files than most applications.

Actually, VMware added this to my /etc/security/limits.conf file:

# Automatically generated by the VMware Installer - DO NOT REMOVE
*               hard    nofile          4096

[Bug 19861] Wine should warn when ulimit -n needs raising

http://bugs.winehq.org/show_bug.cgi?id=19861

--- Comment #29 from Dmitry Timoshkov   2010-06-11 06:11:10 ---
open files != open file handles. This is not about Windows compatibility,
it's about internal implementation. File handles for win32 objects have
nothing to do with file handles in the underlying OS.

[Bug 19861] Wine should warn when ulimit -n needs raising

http://bugs.winehq.org/show_bug.cgi?id=19861

--- Comment #30 from James Huk   2010-06-11 06:28:13 ---
Sorry - but if we follow that logic, wine should not warn when it cannot
initialize OpenGL because for most people it is obvious they need drivers for
that, it should not warn when an application request 16 bit depth,and X server
depth is 24 bits because for most people it is obvious that X cannot switch to
desire bit depth without restart, and so on...

But that would produce false "bugs" and stupid questions from inexperienced
users that's why wine reports the above in console, and should also report
problems with file limit IMHO.

[Bug 19861] Wine should warn when ulimit -n needs raising

http://bugs.winehq.org/show_bug.cgi?id=19861

--- Comment #31 from Dmitry Timoshkov   2010-06-11 06:55:15 ---
(In reply to comment #30)
> Sorry - but if we follow that logic, wine should not warn when it cannot
> initialize OpenGL because for most people it is obvious they need drivers for
> that, it should not warn when an application request 16 bit depth,and X server
> depth is 24 bits because for most people it is obvious that X cannot switch to
> desire bit depth without restart, and so on...

That's obvious cases, and that happens at the initialization time, therefore
easy to catch, and print a FIXME. File handles limit matters at the run-time,
and sometimes it's a legitimate error (really too much open files), which
can happen on Windows as well.

[Bug 19861] Wine should warn when ulimit -n needs raising

http://bugs.winehq.org/show_bug.cgi?id=19861

--- Comment #32 from Octavian Voicu   2010-06-11 07:02:52 ---
(In reply to comment #31)
> File handles limit matters at the run-time,
> and sometimes it's a legitimate error (really too much open files), which
> can happen on Windows as well.

If we want to follow that philosophy we might as well stop coding Wine and tell
everybody to switch to Windows.

It might happen on Windows, but because developers only test their apps with
Windows, they make sure not to reach that limit. If we provide an alternative
Windows API implementation, it has work at least as well as the original one,
but why not even better if we can?

[Bug 19861] Wine should warn when ulimit -n needs raising

http://bugs.winehq.org/show_bug.cgi?id=19861

--- Comment #33 from Dmitry Timoshkov   2010-06-11 07:22:57 ---
(In reply to comment #32)
> (In reply to comment #31)
> > File handles limit matters at the run-time,
> > and sometimes it's a legitimate error (really too much open files), which
> > can happen on Windows as well.
>
> If we want to follow that philosophy we might as well stop coding Wine and tell
> everybody to switch to Windows.

That's not a philosophy, that's just facts.
> It might happen on Windows, but because developers only test their apps with
> Windows, they make sure not to reach that limit. If we provide an alternative
> Windows API implementation, it has work at least as well as the original one,
> but why not even better if we can?

You are confusing things. Windows API implementation is Wine, file handle limit
comes from an underlying OS, and Wine can do nothing about it. Adding a WARN
will not makes the failing apps suddenly work, that obviously has nothing to
do with the quality of the Windows API implementation.

[Bug 19861] Wine should warn when ulimit -n needs raising

http://bugs.winehq.org/show_bug.cgi?id=19861

--- Comment #34 from James Huk   2010-06-11 07:32:34 ---
It may not fix the problem - but it will point out exactly where tho problem is
and how to (easily) fix it.

[Bug 19861] Wine should warn when ulimit -n needs raising

http://bugs.winehq.org/show_bug.cgi?id=19861

--- Comment #35 from Dmitry Timoshkov   2010-06-11 07:44:13 ---
(In reply to comment #34)
> It may not fix the problem - but it will point out exactly where tho problem is
> and how to (easily) fix it.

You are mistaken. Printing an error if OpenGL initialization or screen
resolution change failed doesn't prevent filing bugs with that messages
in the log. Printing a message just helps to diagnose the problem. Running
out of available file handles is a legitimate error, which could happen
even on properly configured systems.

[Bug 19861] Wine should warn when ulimit -n needs raising

http://bugs.winehq.org/show_bug.cgi?id=19861

--- Comment #36 from Dan Kegel   2010-06-11 08:51:00 ---
I feel strongly that we should print a single warning to the winediag channel
in this case, as the patch does, so that the user can complain to whoever
packaged his Wine, or raise the limit on his own in the meantime.

Wine seems to use two fd's per file handle in some situations as a result
of a recent commit, and this causes some real applications to explode
even on Ubuntu, where the fd limit is already set fairly high.  The
failures are mysterious and annoying enough that they merit a +winediag
message.

The exact message should probably be more generic, though, since not all
systems have the same mechanism for raising the limit.

[Bug 19861] Wine should warn when ulimit -n needs raising

http://bugs.winehq.org/show_bug.cgi?id=19861

--- Comment #37 from Octavian Voicu   2010-06-11 10:16:36 ---
(In reply to comment #36)
> The exact message should probably be more generic, though, since not all
> systems have the same mechanism for raising the limit.

That's the best I could come up with. I just checked and I can confirm
/etc/security/limits.conf is used at least on:
- Ubuntu
- Debian
- CentOS
- ScientificSL

Seems to be pretty standard, and I think all PAM-based distros have it. But
even if it won't work on your system, it provides a good starting point to
google for a solution. Suggestions are welcome of course.

[Bug 19861] Wine should warn when ulimit -n needs raising

http://bugs.winehq.org/show_bug.cgi?id=19861

Austin English  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #38 from Austin English   2010-06-11 10:43:31 ---
Fixed by
http://source.winehq.org/git/wine.git/?a=commitdiff;h=0d8e7983c14cd0c8f0672d...

[Bug 19861] Wine should warn when ulimit -n needs raising

http://bugs.winehq.org/show_bug.cgi?id=19861

Alexandre Julliard  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #39 from Alexandre Julliard   2010-06-11 12:51:54 ---
Closing bugs fixed in 1.2-rc3.