Hi,
I'd like to implement delayed debug tracing, by which I mean you can do a +relay,+seh,+tid,+win,+otherstuff and yet not create a log file so huge it's impossible to work with. I seem to recall seeing this feature in WineX, where you can press Alt-F12 to switch it on.
Does anybody who knows the debugging/keyboard code have any particular preferences as to how this should be implemented?
thanks -mike
Le sam 13/12/2003 à 10:56, Mike Hearn a écrit :
Hi,
I'd like to implement delayed debug tracing, by which I mean you can do a +relay,+seh,+tid,+win,+otherstuff and yet not create a log file so huge it's impossible to work with. I seem to recall seeing this feature in WineX, where you can press Alt-F12 to switch it on.
Didn't Eric submitted a tool named wineproc making this possible?
Vincent
On Sat, 13 Dec 2003 15:56:15 +0000, you wrote:
Hi,
I'd like to implement delayed debug tracing, by which I mean you can do a +relay,+seh,+tid,+win,+otherstuff and yet not create a log file so huge it's impossible to work with. I seem to recall seeing this feature in WineX, where you can press Alt-F12 to switch it on.
Does anybody who knows the debugging/keyboard code have any particular preferences as to how this should be implemented?
Gerard Patel (if I remember his name correctly) send in such a patch years ago, which was not committed for obvious reasons.
My way to create a small log goes like this. Start wine like this:
(wine <arguments> & read ans; echo '===') 2>&1 | awk '{if( $1 == "===") flag=1-flag; if(flag) print}' >wine.log
filling the log will only begin after pressing the enter key. Add a while(true), to make it behave as a toggle.
Rein.
On Sat, 2003-12-13 at 16:36, Rein Klazes wrote:
Gerard Patel (if I remember his name correctly) send in such a patch years ago, which was not committed for obvious reasons.
Sorry, I guess the reasons aren't obvious to me. What's wrong with it? Certainly using mini shell scripts like that seems to be more of a hack than special casing some Wine code.
My way to create a small log goes like this. Start wine like this:
(wine <arguments> & read ans; echo '===') 2>&1 | awk '{if( $1 == "===") flag=1-flag; if(flag) print}' >wine.log
filling the log will only begin after pressing the enter key. Add a while(true), to make it behave as a toggle.
That's certainly one way to do it that I hadn't thought of, but it looks rather inefficient.
thanks -mike
On Sat, 13 Dec 2003 16:46:06 +0000, you wrote:
On Sat, 2003-12-13 at 16:36, Rein Klazes wrote:
Gerard Patel (if I remember his name correctly) send in such a patch years ago, which was not committed for obvious reasons.
Sorry, I guess the reasons aren't obvious to me. What's wrong with it?
To my understanding because it does not do that on Windows, probably blocking something needed.
[snip]
That's certainly one way to do it that I hadn't thought of, but it looks rather inefficient.
Of course, it suffers from certain side effects like having to change focus as well.
Rein.
Mike Hearn mike@theoretic.com writes:
Sorry, I guess the reasons aren't obvious to me. What's wrong with it? Certainly using mini shell scripts like that seems to be more of a hack than special casing some Wine code.
Just the opposite, a wrapper script is much cleaner than adding some special handling deep in the Wine core. That way you can define the policy you want (switching on a key press, after a delay, after a certain function is called, etc.) instead of having the Wine core impose its own.
On Sat, 2003-12-13 at 19:56, Alexandre Julliard wrote:
Just the opposite, a wrapper script is much cleaner than adding some special handling deep in the Wine core. That way you can define the policy you want (switching on a key press, after a delay, after a certain function is called, etc.) instead of having the Wine core impose its own.
Only at a great loss of efficiency though. The tradeoff that my patch makes is flexibility for performance - if you are redirecting wines output through wrapper programs and scripts then you have the overhead at least of the IPC, and maybe also text parsing. Simply enabling relay gives a huge speed hit even when not logging things, the last thing wanted is even more overhead.
Of course if you don't want the special cased wine policy you are still free to not use it and use wrapper scripts too.
Well, I am not asking you to like it :) It is making it easier to track down this bug on my slow machine, so that is good.
By the way, does anybody know what 0xeedfade is? The Delphi VCL appears to translate it to EInOutError, but that doesn't tell me much about the underlying Win32 meaning.
thanks -mike
Hi,
On Sat, Dec 13, 2003 at 08:13:54PM +0000, Mike Hearn wrote:
On Sat, 2003-12-13 at 19:56, Alexandre Julliard wrote:
Just the opposite, a wrapper script is much cleaner than adding some special handling deep in the Wine core. That way you can define the policy you want (switching on a key press, after a delay, after a certain function is called, etc.) instead of having the Wine core impose its own.
Only at a great loss of efficiency though. The tradeoff that my patch makes is flexibility for performance - if you are redirecting wines output through wrapper programs and scripts then you have the overhead at least of the IPC, and maybe also text parsing. Simply enabling relay gives a huge speed hit even when not logging things, the last thing wanted is even more overhead.
I have to admit that I also don't quite understand why one would want to implement it externally, due to the massive slowness. One would mainly think of disabling tracing in case of complex programs with huge log files (and which would "conveniently" also take ages to load during relay for the same reason). (with small programs one would most likely say "screw it" and log it fully anyway)
Blowing it through yet another script would probably slow it down by another 20% or so.
By the way, does anybody know what 0xeedfade is? The Delphi VCL appears to translate it to EInOutError, but that doesn't tell me much about the underlying Win32 meaning.
Isn't 0xeedfade just the usual "strange" marker for some weird things in Wine? A grep ought to help here...
Andreas Mohr
On Sat, 2003-12-13 at 20:43, Andreas Mohr wrote:
Isn't 0xeedfade just the usual "strange" marker for some weird things in Wine? A grep ought to help here...
Nah, I found it. A quick hunch and some looking through the Delphi VCL source showed 0xeedfade to be the generic "Native Delphi Exception" error code, ie it's an internal non-win32 exception generated by the delphi compiler itself.
In other words, it's no use at all.
I don't understand why I like working on Wine sometimes. This app is crazy. It actually ships with a linker .map file (text describing symbolic exports, even line number info), and then the program mmaps it and presumably tries to parse it. Why?!? How much more broken can this program get?! It already crashes if it can't find printers or MS Word!
argh, kill me now....
-
Alexandre Julliard -
Andreas Mohr -
Mike Hearn -
Rein Klazes -
Vincent Béron