On Tue, Nov 26, 2002 at 10:23:55PM +0100, Lionel Ulmer wrote:
Hi all,
As long as we do not support multi-texturing in our D3D driver, fill the caps properly. Now SS2 does not try to do multitexturing anymore (not that it actually works now, it's just that it would break less :-) ).
Note: is there a way from DLL X to activate relay debugging ? What happens is that SS2 somehow freezes at one point and doing a relay trace from the start is about a 3 GB file... So what I would like to do is at a specific function in the D3D code that I know to be just before the freeze, call 'activate relay' and voila, I have relaying on :-) (to be able to do that for all DLLs would be even better).
But well, considering DLL separation and all that, I doubt that this would be possible :-/
Oh pleeeeze... I thought that at least the Wine developers are reading the wine docu properly... ;-)
Let's see... first you use completely inacceptable words, and then you admit to never reading the docu... bad, bad, very bad guy. :)
Read wine.man. It explains how to do relay logging for a single DLL. Although I'm afraid that this might actually be broken at the moment maybe :-\
Oh pleeeeze... I thought that at least the Wine developers are reading the wine docu properly... ;-)
You should know now that developpers are the one that read the documentations the less :-)
Read wine.man. It explains how to do relay logging for a single DLL. Although I'm afraid that this might actually be broken at the moment maybe :-\
I do not want to turn on relaying for only one DLL (as I have no clue at all where the problem is)... What I want is to turn on relaying for all DLLs *after* the program has started (and *from* one of Wine's DLL and not from the loader or any other 'special' code).
Ie, the program starts, loads the level / stuff for 10 minutes (and whould have produced a 2.5 GB log unreadable without big file support) and then only the last 10 seconds are important. So I would like to only relay these.
Lionel
Lionel Ulmer [email protected] writes:
Ie, the program starts, loads the level / stuff for 10 minutes (and whould have produced a 2.5 GB log unreadable without big file support) and then only the last 10 seconds are important. So I would like to only relay these.
The easy way would be to print some magic string at that point, and pipe the output into a sed that deletes everything before that string. It will still be a bit slow though.
The harder way is to call wine_dbg_parse_options("+relay"). This would work for a normal debugging option, but for relay there is some work that needs to be done at startup so you need to handle that too. A way would be to start with +relay, turn it off with wine_dbg_parse_options, and then turn it on again when needed.
Alexandre Julliard wrote:
Lionel Ulmer [email protected] writes:
Ie, the program starts, loads the level / stuff for 10 minutes (and whould have produced a 2.5 GB log unreadable without big file support) and then only the last 10 seconds are important. So I would like to only relay these.
The easy way would be to print some magic string at that point, and pipe the output into a sed that deletes everything before that string. It will still be a bit slow though.
The harder way is to call wine_dbg_parse_options("+relay"). This would work for a normal debugging option, but for relay there is some work that needs to be done at startup so you need to handle that too. A way would be to start with +relay, turn it off with wine_dbg_parse_options, and then turn it on again when needed.
As Lionels problem is not by any means unique Iwould think that this should be documented somewhere. I was thinking of adding a section to the wine developers guide along the lines of (semi) Advanced Debuging Techniques. This section would include how to put a breakpoint for some complex condition into the code. and adding some a magic strings to trace logs.
While I am on the subject: as I mentioned in my other mail on this subject. Turning on gdi in winedbg (or any other channel/api that the debugger uses) will include calls from winedebug as well as the program I am debugging. This is an unhelpfull situation.
I think it would be helpfull to change this behavior so that calls from winedbg messages do not get logged along with the programs. Is this possible and if so is it something that someone as faint-of-skill as myself would be able to tackle. Pointers, Comments, Flames...?
While I am on the subject: as I mentioned in my other mail on this subject. Turning on gdi in winedbg (or any other channel/api that the debugger uses) will include calls from winedebug as well as the program I am debugging. This is an unhelpfull situation.
are you sure of this ? debug channels are only changed in the debugged app, not in the debugger aren't you looking at different threads ?
A+
Eric Pouech wrote:
While I am on the subject: as I mentioned in my other mail on this subject. Turning on gdi in winedbg (or any other channel/api that the debugger uses) will include calls from winedebug as well as the program I am debugging. This is an unhelpfull situation.
are you sure of this ? debug channels are only changed in the debugged app, not in the debugger aren't you looking at different threads ?
My appologies. (I am a VERY thick at times) I think most of my problems with this is that I am/was doing it (The Wrong Way) (C) OK. I think I should clarify since I brought it up There are two ways of getting extraneous messages from winedbg in the log.
1). Starting winedbg with --debugmsg +(any channel you want a trace of) ie: +loaddll
2). Any fixme message will get into the log regardless of whether it is generated trough the app or winedbg. I would assume this also applies to err and warn as well but I have not tested them
I think that now that I know about these two conditions (and avoid them) I should be able to get a good clean log.
I tried compiling the latest cvs and heres the error I get.
make[2]: Leaving directory `/root/wine/tools/wrc'
make[1]: Leaving directory `/root/wine/tools'
make[1]: Entering directory `/root/wine/dlls'
make[2]: Entering directory `/root/wine/dlls/ntdll'
make[3]: Entering directory `/root/wine/dlls/ntdll/tests'
LD_LIBRARY_PATH="../../../library:../../../unicode:$LD_LIBRARY_PATH"
../../../tools/winebuild/winebuild -fPIC -DSTRICT -DNONAMELESSUNION
-DNONAMELESSSTRUCT -o
ntdll_test.exe.spec.c -exe ntdll_test.exe -mcui error.o generated.o
rtlbitmap.o rtlstr.o testlist.o -L../../../dlls -L.. -lntdll
could not open .so file for kernel32.dll
make[3]: *** [ntdll_test.exe.spec.c] Error 1
make[3]: Leaving directory `/root/wine/dlls/ntdll/tests'
make[2]: *** [tests] Error 2
make[2]: Leaving directory `/root/wine/dlls/ntdll'
make[1]: *** [ntdll] Error 2
make[1]: Leaving directory `/root/wine/dlls'
make: *** [dlls] Error 2
My appologies. (I am a VERY thick at times) I think most of my problems with this is that I am/was doing it (The Wrong Way) (C) OK. I think I should clarify since I brought it up There are two ways of getting extraneous messages from winedbg in the log.
1). Starting winedbg with --debugmsg +(any channel you want a trace of) ie: +loaddll
2). Any fixme message will get into the log regardless of whether it is generated trough the app or winedbg. I would assume this also applies to err and warn as well but I have not tested them
this would apply to fixme and err which are turned on by default warn and trace are off by default
I think that now that I know about these two conditions (and avoid them) I should be able to get a good clean log.
the point 2/ is complely intented and should be kept as such
regarding point 1/, what you can do is: - start your proces with wine foo --debugmsg +blabla - start winedbg - in winedbg, attach to the running process (using 'walk proc' to get the process id and 'attach pid')
A+
You know... I RTFMed the mplayer documentation maintainer some days ago, though every mail that goes onto the users mailing list is modified with "RTFM" in header and footer... :)))
Oh pleeeeze... I thought that at least the Wine developers are reading the wine docu properly... ;-)
Let's see... first you use completely inacceptable words, and then you admit to never reading the docu... bad, bad, very bad guy. :)
Read wine.man. It explains how to do relay logging for a single DLL. Although I'm afraid that this might actually be broken at the moment maybe :-\
___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com
-
Alexandre Julliard -
Andreas Mohr -
Boris -
Eric Pouech -
Lionel Ulmer -
Sylvain Petreolle -
Tony Lambregts