On Fri, 14 Feb 2003 14:27:11 -0600, you wrote:
Log message: Changed fd operations to take a struct fd instead of a struct object. Removed get_file_info function from object operations. Added get_device_id request to avoid abusing get_file_info.
This breaks newsbin. From the trace:
| 00000009:Call kernel32.CreateFileA(40732b08 "H:\binw\nbpro\LibFilter.dll",80000000,00000001,00000000,00000003,00000080,00000000) ret=100598b5 | 00000009:Ret kernel32.CreateFileA() retval=00000048 ret=100598b5 | 00000009:Call kernel32.CreateFileMappingA(00000048,00000000,00000002,00000000,00000000,00000000) ret=100598d8 | 00000009:Ret kernel32.CreateFileMappingA() retval=00000000 ret=100598d8 | 00000009:Call kernel32.LoadLibraryA(407328d8 "user32") ret=1005a038 | 00000009:Ret kernel32.LoadLibraryA() retval=40810000 ret=1005a038 | 00000009:Call kernel32.GetProcAddress(40810000,407328d8 "MessageBoxA") ret=1005a054 | 00000009:Ret kernel32.GetProcAddress() retval=408b385c ret=1005a054 | 00000009:Call user32.MessageBoxA(00000000,407329f4 "Unable to read this file.",40732b08 "H:\binw\nbpro\LibFilter.dll",00002010) ret=1005a063
Any suggestions?
Rein.
Rein Klazes wrote:
On Fri, 14 Feb 2003 14:27:11 -0600, you wrote:
Log message: Changed fd operations to take a struct fd instead of a struct object. Removed get_file_info function from object operations. Added get_device_id request to avoid abusing get_file_info.
does this unapplied yet patch helps ?
http://www.winehq.com/hypermail/wine-patches/2003/02/0118.html
A+
Eric Pouech wrote:
Rein Klazes wrote:
On Fri, 14 Feb 2003 14:27:11 -0600, you wrote:
Log message: Changed fd operations to take a struct fd instead of a struct object. Removed get_file_info function from object operations. Added get_device_id request to avoid abusing get_file_info.
does this unapplied yet patch helps ?
http://www.winehq.com/hypermail/wine-patches/2003/02/0118.html
You mean this one :-)
Duane Clark wrote:
You mean this one :-)
Oops, I should have looked closer. You didn't mean that one.
Duane Clark wrote:
Duane Clark wrote:
You mean this one :-)
Oops, I should have looked closer. You didn't mean that one.
;-) anyway, Uwe's patch doesn't fix all the issues I have here (it seems there is still an initialized pointer around) A+
Eric Pouech wrote:
;-) anyway, Uwe's patch doesn't fix all the issues I have here (it seems there is still an initialized pointer around)
Another reason to look forward to the coming unification of wine threads with NPTL threads: getting Valgrind running will be easier...
- Dan
On Sun, Feb 16, 2003 at 02:09:30PM -0800, Dan Kegel wrote:
Eric Pouech wrote:
;-) anyway, Uwe's patch doesn't fix all the issues I have here (it seems there is still an initialized pointer around)
Another reason to look forward to the coming unification of wine threads with NPTL threads: getting Valgrind running will be easier...
Which will not help at all with filedescriptors.
Ciao, Marcus
Marcus Meissner wrote:
On Sun, Feb 16, 2003 at 02:09:30PM -0800, Dan Kegel wrote:
Eric Pouech wrote:
;-) anyway, Uwe's patch doesn't fix all the issues I have here (it seems there is still an initialized pointer around)
Another reason to look forward to the coming unification of wine threads with NPTL threads: getting Valgrind running will be easier...
Which will not help at all with filedescriptors.
I thought Eric said there was an uninitialized pointer laying around. Valgrind's real good at finding those... - Dan
Which will not help at all with filedescriptors.
I thought Eric said there was an uninitialized pointer laying around. Valgrind's real good at finding those...
I'm not sure what's uninitialized (maybe a pointer, maybe a fd, maybe something else...) BTW, I don't see what could prevent wineserver to be run under valgrind TODAY It doesn't use threads nor clone nor segmented pointer Did someone already tried running Wine with WINESERVER ? (I didn't, I may try when I'm back home) ? A+
Eric Pouech wrote:
does this unapplied yet patch helps ?
http://www.winehq.com/hypermail/wine-patches/2003/02/0118.html
Well, that fixed the corrupted icons that Uwe mentioned yesterday. However when I exited the program (Xilinx ISE, basically the same as WebPack), it spit out a bunch of cryptic messages:
0x8eb0e30:1: Fd unix_fd=15 mode=000000 user=0x8eb0e70 0x8eb0df0:1: Fd unix_fd=15 mode=000000 user=0x8eb0e30 0x8eb0db0:1: Fd unix_fd=15 mode=000000 user=0x8eb0df0 0x8071ea8:1: Fd unix_fd=15 mode=000000 user=0x8eb0d80 0x8eb0d40:1: Fd unix_fd=15 mode=000000 user=0x8eb0d80 0x8eb0d00:1: Fd unix_fd=15 mode=000000 user=0x8eb0d40 0x8eb0cc0:1: Fd unix_fd=15 mode=000000 user=0x8eb0d00 0x8eb0c80:1: Fd unix_fd=15 mode=000000 user=0x8eb0cc0 0x8eb0c40:1: Fd unix_fd=15 mode=000000 user=0x8eb0c80 0x8eb0c00:1: Fd unix_fd=15 mode=000000 user=0x8eb0c40 0x8eb0bc0:1: Fd unix_fd=15 mode=000000 user=0x8eb0c00 0x8eb0b80:1: Fd unix_fd=15 mode=000000 user=0x8eb0bc0 ... etc, about 40 of them.
"Rein" == Rein Klazes rklazes@xs4all.nl writes:
Rein> On Fri, 14 Feb 2003 14:27:11 -0600, you wrote: >> Log message: Changed fd operations to take a struct fd instead of a >> struct object. Removed get_file_info function from object >> operations. Added get_device_id request to avoid abusing >> get_file_info. >> >> Patch: http://cvs.winehq.com/patch.py?id=7246
Did you try my patch from yetserday?
On Sun, 16 Feb 2003 21:55:44 +0100, you wrote:
"Rein" == Rein Klazes rklazes@xs4all.nl writes:
Rein> On Fri, 14 Feb 2003 14:27:11 -0600, you wrote: >> Log message: Changed fd operations to take a struct fd instead of a >> struct object. Removed get_file_info function from object >> operations. Added get_device_id request to avoid abusing >> get_file_info. >> >> Patch: http://cvs.winehq.com/patch.py?id=7246
Did you try my patch from yetserday?
Ahh, I missed that obvious patch somehow.
Unfortunately, it doesn't help. Neither does current CVS with Alexandres version of the fix.
Rein.
On Mon, 17 Feb 2003 09:39:38 +0100, you wrote:
On Sun, 16 Feb 2003 21:55:44 +0100, I wrote:
Unfortunately, it doesn't help. Neither does current CVS with Alexandres version of the fix.
Oops, now it works. Perhaps I didn't wait log enough for the wineserver to shutdow, it seems to stay up much longer then before. Sorry, for the wrong message.
Rein.