http://bugs.winehq.org/show_bug.cgi?id=4427
------- Additional Comments From dabljuh(a)dabserver.dyndns.org 2006-15-02 06:24 -------
I figured out how to work around the crash. I ran the game in win2k mode. In
Win98 mode I don't have the crashes. So the bug is in ntdll.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=4436
------- Additional Comments From mike(a)codeweavers.com 2006-15-02 05:58 -------
> a badly-written app surely would not try to access the stream after it
> had called the destructor for the storage object? If this is the
> case, then deleting the stream will stop the memory leak.
There's probably applications around that do IStorage_Release followed by
IStream_Release rather than the other way around. If the app leaks memory on
Windows, the best we can do on Wine is to also leak memory.
> It does not make sense that one can open a stream STGM_READWRITE within an
> object opened with STGM_READ, but you can on Windows!
It may have to do with the STGM_TRANSACTED flag that the storage is opened with.
Perhaps OLE storage allows you to write to a stream in that case, but will
refuse to commit it back to the storage?
Unfortunately STGM_TRANSACTED is sorely missing in our OLE Storage implementation...
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=4353
xerox_xerox2000(a)yahoo.co.uk changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ulrich(a)codeweavers.com
------- Additional Comments From xerox_xerox2000(a)yahoo.co.uk 2006-15-02 05:36 -------
i did a regression test , but i think there have been multiple regressions, at
least the errors change while i go back. Anyway , the first patch that broke the
installer was:
http://www.winehq.org/pipermail/wine-cvs/2005-December/019955.html
after this patch the installer just hangs
i'll add the author of the patch;
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=4436
------- Additional Comments From J.A.Gow(a)furrybubble.co.uk 2006-15-02 05:05 -------
OK, I'll change the fix to orphan the stream rather than delete it. The point
is, though is this: a badly-written app surely would not try to access the
stream after it had called the destructor for the storage object? If this is the
case, then deleting the stream will stop the memory leak. However, it looks from
your test that Windows does _not_ delete the stream and thus itself leaks
memory. I thought I had tested this earlier and found that Windows did delete
the streams, but I have just checked my notes and it turned out I was thinking
of a different issue.
That fixes one of the bugs, I'll sort out the patch and submit it. However, what
do you think the best way to handle the other issue (mismatch in grfMode of
opened stream to the grfMode of the storage object)? A test for this was in my
earlier conformance test patch: this following code works on Windows:
r = StgOpenStorage( filename, NULL, 0x00010020, NULL, 0, &stg);
ok(r==S_OK, "StgOpenStorage failed\n");
if(stg)
{
static const WCHAR stmname[] = { 'w','i','n','e','t','e','s','t',0};
IStream *stm = NULL;
r = IStorage_OpenStream( stg, stmname, 0,
STGM_SHARE_EXCLUSIVE|STGM_READWRITE, 0, &stm );
ok(r == S_OK, "OpenStream should succeed - "); printf("rc from
OpenStream : %lx\n",r);
r = IStorage_Release(stg);
ok(r == 0, "wrong ref count\n");
}
It does not make sense that one can open a stream STGM_READWRITE within an
object opened with STGM_READ, but you can on Windows! Should we just remove the
grfMode access flag test from the OpenStream code (as I have done temporarily
just to get the app running)? I will do some testing on Windows to see if I can
identify the access mode flag combinations that succeed and fail, but is there
any knowledge about this problem anywhere else?
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=4482
xerox_xerox2000(a)yahoo.co.uk changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords|regression |
------- Additional Comments From xerox_xerox2000(a)yahoo.co.uk 2006-15-02 04:39 -------
so that's not a regression. The patch just makes sure msvcrt get's loaded as
builtin. So the bug was present before this patch as well, but the native msvcrt
got loaded, that's why it worked. Anyone an idea what debugchanneld to use to
track this down?
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=2853
------- Additional Comments From andi(a)rhlx01.fht-esslingen.de 2006-15-02 03:12 -------
An oprofile run might perhaps help pinpointing what the exact issue is.
I'd say this really needs fixing. It's not acceptable for the interface to the
main Linux sound system to be that broken.
Any freely downloadable non-game apps (media players?) that show this behaviour?
That way it would be more easily debuggable.
I'm not sure whether it helps to have this bug marked "RESOLVED, LATER".
At least there should be another bug clearly finger-pointing at those huge
issues with winealsa.drv.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=4506
------- Additional Comments From mamatkazin(a)ivc.orw.ru 2006-15-02 00:31 -------
Better patch (id=1858) bad!
This patch corrupt screen!
Screenshot attaced.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=4436
------- Additional Comments From mike(a)codeweavers.com 2006-14-02 22:20 -------
> I need to call the destructor for the IStream objects from the code
The child OLE Stream objects should not be destroyed, they should be made to
forget their parent and behave correctly in this case (return STG_E_REVERTED).
They're meant to be released by the program, and the program will leak memory if
they're not released.
I wrote a test to show the behaviour and submitted it to wine-patches:
http://www.winehq.org/pipermail/wine-patches/2006-February/024374.html
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=4221
------- Additional Comments From tkho(a)ucla.edu 2006-14-02 21:14 -------
I can get this working...
The problem is that VistaTask tries to do the "File > Import From" action before
the main Picasa window actually opens. I was able to get the action by adding a
10 second delay.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.