[Bug 32832] New: Wine logs fill the HD in a few seconds and bring down the machine

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

Bug #: 32832
           Summary: Wine logs fill the HD in a few seconds and bring down
                    the machine
           Product: Wine
           Version: 1.5.22
          Platform: x86-64
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: blocker
          Priority: P2
         Component: -unknown
        AssignedTo: [e-mail]
        ReportedBy: [e-mail]
    Classification: Unclassified

After the update to wine-1.5.22, on a kubuntu quantal 64 bit machine, with the
wine shipped through the wine apt repo, I have a huge issue.

Wine floods the screen with 'fixme:wtsapi:WTSWaitSystemEvent Stub (nil)
0x00000078 0x94e964' (which is bad but tolerable).

Most important it fills .wine/drive_c/users/callegar/Application
Data/APP_NAME_NON_STRING/Logs with HUGE log files. In a few seconds these may
reach many GBs, fill the machine HD and bring the machine down.

The log files have names such as
2013.01.28_12.26.08_PID000033_HelperService.HTM
and
2013.01.28_12.26.09_PID000041_ConversionService.HTM

The file giving issues is the helper service one, that gets filled by

Win32 error in file
M:\TemporaryBuilds\2\80\Sources\soda-release\services\HelperService\SessionWatcher.cpp
in line 221 code = 2. Message: File not found.

In just *one second* of wine, this file got to 42MB.

Would be nice if wine did not enable this log mechanism by default, but only
after a command line flag. Also, it would be nice if repeated messages could be
squelched. Finally, why not printing also which file is not found in the log?

As a workaround. Make  .wine/drive_c/users/callegar/Application
Data/APP_NAME_NON_STRING/Logs not writable by anybody.

[Bug 32832] Wine logs fill the HD in a few seconds and bring down the machine

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

Rico  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|blocker                     |normal

--- Comment #1 from Rico  2013-01-28 07:11:01 CST ---
Which app are you using? Does it happen with a clean prefix too?

Searching google for HelperService and APP_NAME_NON_STRING shows that there
might be the same problem on win (for e.g.: PDFCreator or PDF Architect).

Not a blocker, please see
http://bugs.winehq.org/page.cgi?id=fields.html#importance , at best will it is
minor, since an easy workaround is present.

Please run a regression test, see http://wiki.winehq.org/RegressionTesting .

[Bug 32832] Wine logs fill the HD in a few seconds and bring down the machine

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

--- Comment #2 from Sergio Callegari  2013-01-28 07:41:37 CST ---
Hi,

restarted with a clean prefix and this seems to be gone. Apparently something
went wrong with the updating of the config after wine was updated.  Now, apps
cannot find hh.exe anymore, but for the rest the major issue is gone.

I dare to think that the priority should be quite high.  Filling the disk in
this way for a networked machine serving not just the user who is running wine
at the console means almost certain data loss for those who are working from
remote.  And you discover the workaround only after the data loss.

[Bug 32832] Wine logs fill the HD in a few seconds and bring down the machine

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

--- Comment #3 from Rico  2013-01-28 07:56:44 CST ---
You have not stated which app you were using, so we could not help you, I
think. But I think it may be PDF Creator or so ... Did you had that installed?
You may have a look here
http://forums.pdfforge.org/discussion/10469/helperservice-exe-belegt-komplet...
, it's in german ...

If a user should not be able to fill the disk, you may use a disk quota ... but
that's another issue and has nothing to do with wine.

[Bug 32832] Wine logs fill the HD in a few seconds and bring down the machine

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

--- Comment #4 from Rico  2013-01-28 09:06:50 CST ---
Don't get me wrong, I still think there might be a problem in wine.

You may search the hh.exe (it should be in $prefix/drive_c/windows - if it is
the default prefix then ~/.wine/drive_c/windows). If it is not there, there may
be a packaging issue. It should be there if you create a new prefix and have a
look in there (see http://wiki.winehq.org/FAQ#wineprefix ).

Which wine version was the last working one? (before you did the wine update)

[Bug 32832] Wine logs fill the HD in a few seconds and bring down the machine

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

--- Comment #5 from Sergio Callegari  2013-01-28 09:13:05 CST ---
Hi,

the app that I am using is LT-Spice. The bug was probably related to an install
of Soda PDF that after uninstall left something around that wine could not
manage correctly on update from the previous minor version.

For what concerns the help file, I am sure it is a problem of LT-Spice. It
tries to detect wine to second it, and probably in some occasions it makes
wrong guesses.

For some reasons, hh is in place, but scad3 when asked to show its help opens a
wine explore window. If from there I find the ltspice chm and I click on it
another wine explore window opens. Weird

For the disk, I know that quotas can save the day, but in this case the user
was myself, so I thought I did not need it. Unfortunately by filling the disk I
ruined the work of someone who was working from remote. The fact that scared me
was that the filling was so fast that the disk notifier did not even have time
to alert me.

[Bug 32832] Wine logs fill the HD in a few seconds and bring down the machine

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

--- Comment #6 from Austin English  2013-01-28 13:38:48 CST ---
Testing in a clean prefix (without cruft from uninstalled programs) would also
be useful.

[Bug 32832] Wine logs fill the HD in a few seconds and bring down the machine

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

--- Comment #7 from Sergio Callegari  2013-01-30 04:03:05 CST ---
Hi,

as mentioned working in a clear prefix solves the issue. This is certainly more
related to some misbehaving windows application than to wine.

I believe that the bug can possibly be closed. Sorry for the noise.

Two more notes:

- Would be nice if wine could define quotas for its drives, rather than setting
quotas for the whole homes of the users of wine. Or anyway introduce some
system to avoid filling the user's home. Note that setting quotas for users,
can avoid the machines from coming down if the wine 'drives' start taking too
much space, but will not prevent data loss if the disk suddendly fills and the
user has some other apps working. Unfortunately, many apps when trying to save
to disk do not fail gracefully if the disk is full, but corrupt the whole
document. So the risk of data loss is important.

- After re-starting with a new prefix, I had to reinstall applications. Many
apps that used to go to "Program Files" now go to "Program files (x86)" during
install (I do not know if this is a change in the apps or in wine). However the
result is that for some apps the help system breaks. I have made a few tests
and it looks like it is the "()" in the path that creates issues.  I have
posted a separated bug for this as 32833.

[Bug 32832] Wine logs fill the HD in a few seconds and bring down the machine

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

--- Comment #8 from Nikolay Sivov  2013-01-30 04:20:09 CST ---
(In reply to comment #7)
> Two more notes:
> - Would be nice if wine could define quotas for its drives, rather than setting
>
> quotas for the whole homes of the users of wine. Or anyway introduce some
> system to avoid filling the user's home. Note that setting quotas for users,
> can avoid the machines from coming down if the wine 'drives' start taking too
> much space, but will not prevent data loss if the disk suddendly fills and the
> user has some other apps working. Unfortunately, many apps when trying to save
> to disk do not fail gracefully if the disk is full, but corrupt the whole
> document. So the risk of data loss is important.

That's should be done at system level, wine doesn't know about quotas.
> - After re-starting with a new prefix, I had to reinstall applications. Many
>
> apps that used to go to "Program Files" now go to "Program files (x86)" during
> install (I do not know if this is a change in the apps or in wine). However the
> result is that for some apps the help system breaks. I have made a few tests
> and it looks like it is the "()" in the path that creates issues.  I have
> posted a separated bug for this as 32833.

That change in path means you're running win64-capable wine now, and 32bit
applications are installed in (x86) subdir. That's how it works. To verify if
that's really '(' that makes a difference you need to create some dir outside
on 'Program Files', on C: root for example and try with it.

[Bug 32832] Wine logs fill the HD in a few seconds and bring down the machine

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

--- Comment #9 from Sergio Callegari  2013-01-30 04:26:53 CST ---
Maybe suggesting that users of wine are in a wine group, making .wine owned by
group wine and sgid and applying a group quota on wine could be a viable
solution?

[Bug 32832] Wine logs fill the HD in a few seconds and bring down the machine

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

--- Comment #10 from Austin English  2013-01-30 13:24:13 CST ---
(In reply to comment #9)
> Maybe suggesting that users of wine are in a wine group, making .wine owned by
> group wine and sgid and applying a group quota on wine could be a viable
> solution?

That's a system administrator decision. Wine expects the WINEPREFIX to be
owned/controlled by the user running it, not for them to be shared between
multiple users/groups.

[Bug 32832] Wine logs fill the HD in a few seconds and bring down the machine

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

--- Comment #11 from Sergio Callegari  2013-01-30 13:39:53 CST ---
Well, it was not meant for sharing the directory WINEPREFIX among multiple
users. It is the typical workaround for the fact that most filesystems (with a
few exceptions) do not support per-directory quotas, so that a quota cannot be
attached to the WINEPREFIX. Basically you create a group for each directory you
want a quota on and you use group quotas.

But I agree it is clumsy and cannot be implemented without the aid of the
admin.

[Bug 32832] Wine logs fill the HD in a few seconds and bring down the machine

https://bugs.winehq.org/show_bug.cgi?id=32832

Austin English  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #12 from Austin English  ---
Invalid.

[Bug 32832] Wine logs fill the HD in a few seconds and bring down the machine

https://bugs.winehq.org/show_bug.cgi?id=32832

Austin English  changed:

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

--- Comment #13 from Austin English  ---
Closing.