http://bugs.winehq.org/show_bug.cgi?id=4436
------- Additional Comments From J.A.Gow(a)furrybubble.co.uk 2006-13-02 07:25 -------
Nice ASCII art :)
This is close to what I had in mind, but the problem I found was to ensure that
well-behaved apps (i.e. ones that correctly call IStream_Release before
IStorage_Release) worked as well as badly behaved ones (that called
IStorage_Release and expected all streams to be closed and destroyed at this
time) without either creating an object leak.
As I see it this requires the following behaviour:
We maintain the list of stream objects in the storage object. When the storage
destructor is called, before killing the storage object we iterate the list of
stream objects. If any are left (badly behaved app) we kill them by calling the
IStream destructor for each object in the list, before killing the storage object.
Now this is OK, except for the case of a well behaved app that correctly calls
the stream object destructor before the storage object destructor. In this case,
the stream object destructor will have to inform the storage object that the
stream object should be removed from the list of stream objects maintained by
the storage object. If the stream object is not removed from the list, when the
storage object destructor is called it will attempt to kill the
already-destroyed stream object when it finds it in the list. Hey presto- segfault!.
So we need an interface by which a stream object can communicate its imminent
destruction to the storage object in which it lives - the direction of
communication would be stream object -> storage object.
And it is here where I am not sure how to proceed. I have the list management
stuff coded in the storage object but I need advice on how best to introduce an
interface for communication between a stream object destructor and the storage
object in which it resides.
In your suggestion, it seems that we are not killing the outstanding stream
objects when the outstanding Storage objects are destroyed. Surely this would
guarantee a memory leak for a badly behaved app? Since it would seem no app
would explicitly destroy the stream object and then afterwards try and use the
streams created within it during its scope, would it not make more sense to kill
outstanding streams with closure of the storage object and avoid the memory
leak? I agree it breaks the object rules somewhat, but then it looks like
Windows does too!
--
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=4561
------- Additional Comments From chris.bainbridge(a)gmail.com 2006-13-02 07:01 -------
*** Bug 4559 has been marked as a duplicate of this bug. ***
--
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=4559
chris.bainbridge(a)gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |DUPLICATE
------- Additional Comments From chris.bainbridge(a)gmail.com 2006-13-02 07:01 -------
This goes away when I use framebuffer driver, is a dupe of my other bug report.
*** This bug has been marked as a duplicate of 4561 ***
--
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=4561
------- Additional Comments From chris.bainbridge(a)gmail.com 2006-13-02 06:14 -------
I have tried the binary on the same platform but different PC and it works.
There is something odd going which seems hardware specific (the only major
differences I can think of are that I'm using ati binary drivers). I'll retry
without the ati drivers.
--
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=4561
chris.bainbridge(a)gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
OS/Version|other |Linux
Platform|Other |PC
Version|0.9.7. |CVS
--
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=4570
Summary: dbghelp.dll.so: symbol regexec not defined in libc.so.6
Product: Wine
Version: 0.9.7.
Platform: PC
URL: http://www.ag.ch/steueramt/de/pub/angebote/steuererklaer
ungen.php
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: wine-misc
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: moz(a)liebesgedichte.siteware.ch
The programm EasyTax 2005 (get a free version from the provided link) fails with
the following output:
wine "C:\Program Files\EasyTax\AG2005\EasyTax2005_AG.exe"
err:ole:CoGetClassObject class {00000514-0000-0010-8000-00aa006d2ea4} not registered
err:ole:create_server class {00000514-0000-0010-8000-00aa006d2ea4} not registered
fixme:ole:CoCreateInstance no classfactory created for CLSID
{00000514-0000-0010-8000-00aa006d2ea4}, hres is 0x80040154
wine: Unhandled exception 0x0eedfade at address 0x0000:0x7fcb08d0 (thread 0009),
starting debugger...
err:module:load_builtin_dll failed to load .so lib for builtin L"dbghelp.dll":
/usr/lib/wine/dbghelp.dll.so: symbol regexec, version GLIBC_2.3.4 not defined
infile libc.so.6 with link time reference
err:module:import_dll Loading library dbghelp.dll (which is needed by
L"C:\\windows\\system32\\winedbg.exe") failed (error c000007a).
err:module:LdrInitializeThunk Main exe initialization for
L"C:\\windows\\system32\\winedbg.exe" failed, status c0000135
Is this a compatibility problem with the glibc of debian stable or a something
else? Using the builds from http://wine.sourceforge.net/apt/. Any help appreciated.
--
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=4558
------- Additional Comments From Speeddymon(a)gmail.com 2006-12-02 23:42 -------
what winver are you using? if it is win98, try changing it to winxp or win2k.
--
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=4562
vitaliy(a)kievinfo.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |WONTFIX
------- Additional Comments From vitaliy(a)kievinfo.com 2006-12-02 23:16 -------
You know better then anyone else that there are stuff that is not so important.
This being one of them.
--
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=4561
------- Additional Comments From vitaliy(a)kievinfo.com 2006-12-02 23:15 -------
Please install NOT STRIPPED wine and _attach_ back trace again.
Olse update your HW/OS. And specify distro.
Thanks.
--
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.