Good day!
One or all of these 3 patches has somehow broken fault hanlding for my mail app. As I seem to have it sort of working again, I wanted to get out a warning, and sorry I can't be more specific yet. The app also doesn't like to be forced to use a local phone number that is not in its current list but still works. I can't blame it, but I am damned if I will have it adding $.05 to my phone bill every time I send or get mail. I got what looked like a recursive page fault somewhere in startup/fixup_imports until I reverted all 3. It _might_ be a local misconfiguration, so don't waste too much time on it, but if you spot something that could be a bit wrong in one of these patches, please let me know.
N 1 Apr 23 Alexandre Julliard (2,414) wine/dlls/msvcrt time.c N 2 Apr 23 Alexandre Julliard (2,089) wine/include/msvcrt stddef.h N 3 Apr 23 Alexandre Julliard (2,071) wine/debugger types.c
I can't see how it could be any of them, but I guess it must be stddef.h. The app insists so far on native msvcrt. I keep hoping that will change.
Regards,
Lawson ---cut here
________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.
On Tue, 24 Apr 2001 lawson_whitney@juno.com wrote: [...]
I got what looked like a recursive page fault somewhere in startup/fixup_imports until I reverted all 3. It _might_ be a local misconfiguration, so don't waste too much time on it, but if you spot something that could be a bit wrong in one of these patches, please let me know.
N 1 Apr 23 Alexandre Julliard (2,414) wine/dlls/msvcrt time.c N 2 Apr 23 Alexandre Julliard (2,089) wine/include/msvcrt stddef.h N 3 Apr 23 Alexandre Julliard (2,071) wine/debugger types.c
I can't see how it could be any of them, but I guess it must be stddef.h. The app insists so far on native msvcrt. I keep hoping that will change.
If you're using native msvcrt then the first two should have no impact. If you meant that the crash only occurs when you try using the builtin msvcrt then maybe it's the patch to time.c. But I would still don't see why... quite the opposite. Let us know if you find out more about this.
-- Francois Gouget fgouget@free.fr http://fgouget.free.fr/ {free} || die "";
On Tue, 24 Apr 2001, Francois Gouget wrote:
If you're using native msvcrt then the first two should have no impact. If you meant that the crash only occurs when you try using the builtin msvcrt then maybe it's the patch to time.c. But I would still don't see why... quite the opposite. Let us know if you find out more about this.
-- Francois Gouget fgouget@free.fr http://fgouget.free.fr/ {free} || die "";
I thought I saw that wine itself is now using the msvcrt headers, so maybe a macro... no, I can't see that it is. crtdll defaults to builtin:
[DllOverrides] "*" = "builtin, so, native"
[AppDefaults\juno.exe\DllOverrides] "msvcrt" = "native" "riched32" = "native"
but AFAIK, the app doesn't use crtdll. No, if I'd had builtin msvcrt working and a patch made it crash, I would just debug that, I think.
It may take a while, but I will worry at it until I find it.
Thanks
Lawson ---cut here
________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.
On Tue, 24 Apr 2001 lawson_whitney@juno.com wrote:
On Tue, 24 Apr 2001, Francois Gouget wrote:
If you're using native msvcrt then the first two should have no impact. If you meant that the crash only occurs when you try using the builtin msvcrt then maybe it's the patch to time.c. But I would still don't see why... quite the opposite. Let us know if you find out more about this.
I thought I saw that wine itself is now using the msvcrt headers, so maybe a macro... no, I can't see that it is.
Only the sources of the msvcrt dll use the msvcrt headers. This helps find bugs and make sure things are coherent. Normally the other libraries don't use the msvcrt headers (I don't think there would be any reason for them to). So all problems should be restricted to the msvcrt library.
-- Francois Gouget fgouget@free.fr http://fgouget.free.fr/ 1 + e ^ ( i * pi ) = 0
On Tue, 24 Apr 2001, Francois Gouget wrote:
If you're using native msvcrt then the first two should have no impact. If you meant that the crash only occurs when you try using the builtin msvcrt then maybe it's the patch to time.c. But I would still don't see why... quite the opposite. Let us know if you find out more about this.
-- Francois Gouget fgouget@free.fr http://fgouget.free.fr/ {free} || die "";
I have got the first 2 back in again and it seems still to work, so I guess you are exculpated. That leaves only the debugger patch or my own fat fingers.
Lawson
It is impossible to make anything foolproof because fools are so ingenious. ---cut here
________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.
I have got the first 2 back in again and it seems still to work, so I guess you are exculpated. That leaves only the debugger patch or my own fat fingers.
don't want to be sarcastic at your fingers, but I don't see how a fix in the debugger could change the way an app work when the debugger is not launched... did you try to run the app with the debugger started before the crash to see where you get the first fault ?
A+
On Tue, 24 Apr 2001, eric pouech wrote:
don't want to be sarcastic at your fingers, but I don't see how a fix in the debugger could change the way an app work when the debugger is not launched... did you try to run the app with the debugger started before the crash to see where you get the first fault ?
A+
Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle
I don't either, but that is what seems to be happening. Do you mean start the debugger by itself and attach the app before it faults, or run the app with the debugger?
I applied the patch by itself. Of installable things, that changes only the debugger, but I installed whatever make install sees fit to install. The app won't start. I restored only the debugger from a local.tar, since only it changed. The app still won't start. I restored all of local to the state before the patch and it will. This makes so little sense I am embarassed to write about it. I am going to go out and get some fresh air and see if it can clear my head.
Okay, it started raining, so I only did 8km on the push-bike instead of 16, but it seems to have helped. If you get this, it comes by wine with the debugger patch in. It seems I was getting HD errors which were causing wine to hang and otherwise misbehave. Load a library, and when you are done there is nothing there, so when the init code gets called, it faults. reverting moved the files to sectors that happened to work. I should have known when the same version of wine worked on one box and not on the other for the same app (shared by nfs) but at the time it only made my head hurt. e2fsck -c has fixed it for now, but sterner measures may become necessary.
Sorry for the noise, and thanks for insisting on common sense. There was nothing wrong with any of those patches after all.
Lawson
It is impossible to make anything foolproof because fools are so ingenious. ---cut here
________________________________________________________________ GET INTERNET ACCESS FROM JUNO! Juno offers FREE or PREMIUM Internet access for less! Join Juno today! For your FREE software, visit: http://dl.www.juno.com/get/tagj.
Do you mean start the debugger by itself and attach the app before it faults, or run the app with the debugger? it could be either way. The later is a bit easier to do. I just wanted to get rid of the debugger startup code when an exception occurs... if you've already messed a lot with the memory, you may not be able to start the debugger. For example, the debugger launch code uses the Heap (from CreateProcess), which be give strange results...
Sorry for the noise, and thanks for insisting on common sense. There was nothing wrong with any of those patches after all.
no sweat ;-)
A+
-
eric pouech -
Francois Gouget -
lawson_whitney＠juno.com