August 2004 - Wine-Devel - list.winehq.org

Re: "winetest" throws an exception after the unsuccessful send operation

by Saulius Krasuckas

On Wed, 18 Aug 2004, Saulius Krasuckas wrote: > On Wed, 18 Aug 2004, Ferenc Wagner wrote: > > as I can't see why buffer should be dynamic at all. Please > > check it in case I made another mistake: > > Ok then. In this case "my" part of the patch can be omitted: > ..as "buffer" doesn't need to be preserved anymore. =) Sorry for that nonsense. Maybe I got overheated today.

Aug. 18, 2004

Re: Backtrace Dumps

by Robert Shearman

Andreas Mohr wrote: >P.S.: no offense to Eric. He's done TONS of very useful things to winedbg, >and when considering how many fatal architecture changes winedbg had >to go through, it's amazing that it still works pretty well. :-) > > Yes, without his work this patch would have been impossible. A lot of the debugger has now been moved into dbghelp so that it can be used by other things than just the debugger. Rob

Aug. 18, 2004

Re: "winetest" throws an exception after the unsuccessful send operation

by Saulius Krasuckas

On Wed, 18 Aug 2004, Ferenc Wagner wrote: > > We can use the "str" instead of the "buffer". I've tried > > such mod and it worked fine in my case: > > Yes, your patch is good. Still I recommend something more, > as I can't see why buffer should be dynamic at all. Please > check it in case I made another mistake: Ok then. In this case "my" part of the patch can be omitted: > @@ -209,17 +208,15 @@ > if (ret) { > buffer[total] = 0; > str = strstr (buffer, "\r\n\r\n"); > - if (str) buffer = str + 4; > + str = str ? str+4 : buffer; > report (R_ERROR, "Can't submit logfile '%s'. " > - "Server response: %s", name, buffer); > + "Server response: %s", name, str); > } ..as "buffer" doesn't need to be preserved anymore. =)

Aug. 18, 2004

Re: WineSetupTk...

by Ivan Leo Puoti

>Ivan, do we need to remove links to sourceforge since its no longer >available? Actually iy is, but it isn't listed on the download page. Like all files on sf, you can't remove a release, but you can hide it. >I would guess so.. So do you want to do it or me? I'll send in a patch. Ivan.

Aug. 18, 2004

Re: "winetest" throws an exception after the unsuccessful send operation

by Ferenc Wagner

> Is it OK to try to free the modified "buffer" ptr? I > thought we should preserve its value. Yes, you are right, that code is illegal. The wonderful thing is that it's more than half a year old, and went unnoticed this far! Probably because the WineHQ server never failed during that period. Amazing. I wonder what have happened to it now. > We can use the "str" instead of the "buffer". I've tried > such mod and it worked fine in my case: Yes, your patch is good. Still I recommend something more, as I can't see why buffer should be dynamic at all. Please check it in case I made another mistake: Index: programs/winetest/send.c =================================================================== RCS file: /home/wine/wine/programs/winetest/send.c,v retrieving revision 1.12 diff -u -r1.12 send.c --- programs/winetest/send.c 6 Jul 2004 21:03:22 -0000 1.12 +++ programs/winetest/send.c 18 Aug 2004 11:26:02 -0000 @@ -107,7 +107,7 @@ SOCKET s; FILE *f; #define BUFLEN 8192 - unsigned char *buffer; + unsigned char buffer[BUFLEN+1]; size_t bytes_read, total, filesize; char *str; int ret; @@ -127,7 +127,6 @@ "Upload File\r\n" "--" SEP "--\r\n"; - buffer = xmalloc (BUFLEN + 1); s = open_http ("test.winehq.org"); if (s == INVALID_SOCKET) return 1; @@ -209,17 +208,15 @@ if (ret) { buffer[total] = 0; str = strstr (buffer, "\r\n\r\n"); - if (str) buffer = str + 4; + str = str ? str+4 : buffer; report (R_ERROR, "Can't submit logfile '%s'. " - "Server response: %s", name, buffer); + "Server response: %s", name, str); } - free (buffer); return ret; abort2: fclose (f); abort1: close_http (s); - free (buffer); return 1; } Thanks for the good spotting, Feri.

Aug. 18, 2004

"winetest" throws an exception after the unsuccessful send operation

by Saulius Krasuckas

I am getting this after all the tests were performed, network transfer of the report file was over and after the http server has responded (with some error-message) in Wine: err:win:WIN_FindWndPtr window 0x10022 belongs to other process err:win:WIN_FindWndPtr window 0x10022 belongs to other process wine: Unhandled exception (thread 000b), starting debugger... fixme:console:SetConsoleCtrlHandler (0x4067a644,1) - no error checking or testing yet WineDbg starting on pid 0xa Unhandled exception: page fault on read access to 0xffe5024c in 32-bit code (0x40045cf2). In 32 bit mode. 0x40045cf2 pthread_mutex_lock in libpthread.so.0: movl 0xc(%edi),%eax Wine-dbg>bt Backtrace: =>1 0x40045cf2 pthread_mutex_lock+0x12 in libpthread.so.0 (0x40c0fe28) 2 0x42075bea free+0x9a in libc.so.6 (0x40c0fe48) 3 0x4065753a send_file+0x362(name=0x781e4a80) [send.c:217] in winetest (0x40c0fe78) 4 0x40656f2e .L256+0xde in winetest (0x40c0fe9c) 5 0x4065511c __wine_exe_main+0x11c in winetest (0x40c0ff2c) 6 0x403a101a start_process+0xf2(arg=0x0) [process.c:995] in kernel32 (0x40c0fff4) 7 0x4002a8cd wine_switch_to_stack+0x11 in libwine.so.1 (0x00000000) And the error message in the message-box looks like this: Can't submit logfile '/tmp/rescVOMCP'. Server response: <!DOCTYPE HTML PUBLIC"... ... <title>500 Internal Server Error</title> ... <p>The server encountered an internal error or misconfiguration and was unable to complete your request.</p> ... <address>Apache 2.0.40 Server at test.winehq.org Port 80</address> <body><html> Back to the code. Excerpts from the programs/winetest/send.c: > unsigned char *buffer; ... > buffer = xmalloc (BUFLEN + 1); ... > if (ret) { > buffer[total] = 0; > str = strstr (buffer, "\r\n\r\n"); > if (str) buffer = str + 4; > report (R_ERROR, "Can't submit logfile '%s'. " > "Server response: %s", name, buffer); > } > free (buffer); Is it OK to try to free the modified "buffer" ptr? I thought we should preserve its value. We can use the "str" instead of the "buffer". I've tried such mod and it worked fine in my case: --- wine/programs/winetest/send.c 6 Jul 2004 21:03:22 -0000 1.12 +++ wine/programs/winetest/send.c 18 Aug 2004 07:41:24 -0000 @@ -209,9 +209,9 @@ if (ret) { buffer[total] = 0; str = strstr (buffer, "\r\n\r\n"); - if (str) buffer = str + 4; + str = (str)?(str + 4):(buffer); report (R_ERROR, "Can't submit logfile '%s'. " - "Server response: %s", name, buffer); + "Server response: %s", name, str); } free (buffer); return ret; Should I submit it to the wine-patches or I am wrong with it?

Aug. 18, 2004

Re: Backtrace Dumps

by Andreas Mohr

Hi, On Wed, Aug 18, 2004 at 09:27:53AM +0100, Mike Hearn wrote: > My problem with this approach is that it relies on the exception > actually getting through to the debugger instead of being trapped by the > program code and swallowed. I guess we could install a vectored handler > to boot the debugger and such but now the code is a lot more complex and > confusing for newbies than just having some inline functions in the > headers. As if the SEH code wasn't already confusing enough! Indeed. I'm sure every semi-involved Wine developer can imagine dozens of "reasons of the day" why winedbg doesn't launch properly on error again... Failure in wine exception handling code, failure to look up winedbg (both registry and disk), failure to pass winedbg cmdline parameters properly, failure to get winedbg started up properly, failure to get winedbg to parse the current modules and stack frame properly, ... That's why a "no frills" debugging mechanism is a good idea IMHO. Andreas Mohr P.S.: no offense to Eric. He's done TONS of very useful things to winedbg, and when considering how many fatal architecture changes winedbg had to go through, it's amazing that it still works pretty well. :-)

Aug. 18, 2004

Re: iostream and msvcrt?

by Boaz Harrosh

Scott Snell wrote: >Is that simpler than fixing the MSVCRT headers? > It is not wine-MSVCRT headers fault, these are pure CRT declarations. It is gcc-c++ headers that are heavily dependent on gcc CRT very non-standard headers. So you better go with STLPort. >I have used STLport before >so the idea sounds feasable to me. I imagine I have to change the >gcc-linux.mak by: > >replacing the call to gcc with winegcc, >removing references to GLIBC, > > Better go with gcc-mingw.mak, as threading and OS is more Windows than Linux. See if they have a -nocygwin variant. >adding a path pointing to /include/wine/MSVCRT. > > > Yes exactly. You'll see that you end up with a complete xxx-wine set of makefiles and headers. >Anything else? > > > There are some 1-2 defines in the major ARCH headers that go the windows way. I remember I had to define a __WINE_GCC__ in makefile and in a couple of places where they have this heavy #ifdef this #elseif that - I had to add #ifdef __WINE_GCC__ to point the compiler the windows way. But I guess the compiler will show you soon enough where he took the wrong turn. I'll try to dig out that HD anyway Just so we can compare notes. But I'm sure you'll manage before I have time to do that. >regards, > >Scott. > > Free Life Boaz

Aug. 18, 2004

Re: Backtrace Dumps

by Mike Hearn

Me too! *jumps up and down* In Java you can say this: new Exception().printBackTrace(); or some equivalent to get a printout of where you are, and it's very convenient. I can see the reasoning behind keeping the code in the debugger then triggering it using a custom exception though, as that way we only have one piece of backtracing code. My problem with this approach is that it relies on the exception actually getting through to the debugger instead of being trapped by the program code and swallowed. I guess we could install a vectored handler to boot the debugger and such but now the code is a lot more complex and confusing for newbies than just having some inline functions in the headers. As if the SEH code wasn't already confusing enough! > Wine has always had massive problems with getting easily accessible > debugging/diag support (doing debugging stuff IS hard, no question here...). > Thus I think we generally want not less, but more support, as long as it > helps (and as long as it doesn't cause a maintenance headache > or ill-maintained subsystems due to too much "choice" in debugging options...). > Since I'd think that that backtrace code should be fairly small and > self-maintaining, I'd vote for including it.

Aug. 18, 2004

Re: More winecfg todos

by Saulius Krasuckas

On Wed, 18 Aug 2004, Izak Burger wrote: > How about the Debian way of adding stubs to a .d directory... > > wine.d with lots of small easily editable .reg files. I'm sure this is > a silly suggestion, but if you REALLY have a problem with a 5000 line > .reg file (I sure did when I had to configure squid.. uggh), nothing > prevents you from doing this yourself and having a update-wine.conf > script, Debian style (refering to their exim4 setup). I have never been using the Debian distro and have no experience with a .d directories. Is there any newbie intro to this stuff on the net? Thanks. > Mike Hearn wrote: > > Maybe we should fork the Wine/Config branch into a separate .reg file to > > appease those who want to edit it using a text editor. That would make > > the switch from config file -> registry less obvious. Not exactly the > > same of course, no comments for one, no defaults to show you what they > > are for another, but it might be an improvement?

Aug. 18, 2004