WineHQ
Wine Forums

Board index » WineHQ » Wine Help




 Page 1 of 2 [ 28 posts ] Go to page 1, 2  Next



 
Author Message
 Post Posted: Fri Mar 07, 2008 6:16 pm 
 
Hi all,
I did my first bug report in a while. Unfortunately the good folks
at wineHQ.org didn't like it much because Gentoo by default stripped
out much of the backtrace info. I've recompiled Wine with more
backtrace capabilities in it and am wondering what's considered good
enough.

Below are two backtraces. They may or may not be exactly the same
failure but they both come from the same program doing similar things.
(Testing the system hardware for compatibility.) The first one is the
older one. The second is newer. My question is whether the second is
considered 'good enough' to be genuinely helpful?

Eventually, when I get a 'good' backtrace then I'll capture the 3
or 4 ways the program fails and submit all the data for the developers
but currently I'm just trying to get the basics working well enough to
be helpful.

Thanks,
Mark


Backtrace:
=>1 0x127f:0x9de9 (0x12c7:0x537a)
2 0x129f:0x5265 (0x12c7:0x538a)
3 0x129f:0x538f (0x12c7:0x53a0)
4 0x129f:0x1c8b (0x12c7:0x53d4)
5 0x129f:0x1833 (0x12c7:0x53ea)
6 0x1287:0x3945 (0x12c7:0x53fe)
7 0x1287:0x3a61 (0x12c7:0x5424)
8 0x1287:0x2e23 (0x12c7:0x5442)
9 0x1287:0x203d (0x12c7:0x5464)
10 0x1287:0x1c57 (0x12c7:0x54b0)
11 0x1287:0x11c7 (0x12c7:0x5504)
12 0x1287:0x1318 (0x12c7:0x551c)
13 0x101f:0x0468 in kernel32 (+0x7e30c) (0x12c7:0x5556)
14 0x7ee8d48e K32WOWCallback16Ex+0xce() in kernel32 (0x7dade858)
15 0x7ed0cdfe WINPROC_wrapper+0x50e() in user32 (0x7dadeb98)
16 0x7ed0f86c in user32 (+0xaf86c) (0x7dadf098)
17 0x7ed10dda in user32 (+0xb0dda) (0x7dadf0c8)
18 0x7ed10f61 in user32 (+0xb0f61) (0x7dadf768)
19 0x7ed1326f in user32 (+0xb326f) (0x7dadf7a8)
20 0x7ecd8232 in user32 (+0x78232) (0x7dadf818)
21 0x7ecdbfb9 in user32 (+0x7bfb9) (0x7dadf878)



Backtrace:
=>1 0x128f:0x462d (0x12c7:0x4f54)
2 0x128f:0x44f5 (0x12c7:0x5094)
3 0x128f:0x3a73 (0x12c7:0x5206)
4 0x1287:0x1e92 (0x12c7:0x5252)
5 0x1287:0x11c7 (0x12c7:0x52a6)
6 0x1287:0x1318 (0x12c7:0x52be)
7 0x101f:0x0468 __wine_call_to_16_ret() in kernel32 (0x12c7:0x52f8)
8 0x7ee8d48e K32WOWCallback16Ex+0xce() in kernel32 (0x7dad83d8)
9 0x7ed00dfe call_window_proc16+0x16e() in user32 (0x7dad8718)
10 0x7ed0386c WINPROC_CallProc32ATo16+0x101c() in user32 (0x7dad8c18)
11 0x7ed04dda call_window_proc_Ato16+0x4a() in user32 (0x7dad8c48)
12 0x7ed04f61 WINPROC_CallProcWtoA+0x181() in user32 (0x7dad92e8)
13 0x7ed0726f WINPROC_call_window+0x1df() in user32 (0x7dad9328)
14 0x7ecccbaf DispatchMessageW+0x9f() in user32 (0x7dad9368)
15 0x7ec9987f IsDialogMessageW+0x10f() in user32 (0x7dad94c8)
16 0x7ec9a22f DIALOG_DoDialogBox+0xdf() in user32 (0x7dad9528)


Top 
 Post Posted: Fri Mar 07, 2008 6:25 pm 
 
On Fri, Mar 7, 2008 at 3:16 PM, Mark Knecht <markknecht@gmail.com> wrote:
Quote:
16 0x7ec9a22f DIALOG_DoDialogBox+0xdf() in user32 (0x7dad9528)

Hi Mark, thanks for asking! Sadly, that trace doesn't have
line numbers. Perhaps that info was stripped out
during install; try running the wine that's in the build
directory (if you can).


Top 
 Post Posted: Fri Mar 07, 2008 6:47 pm 
 
On Fri, Mar 7, 2008 at 3:25 PM, Dan Kegel <dank@kegel.com> wrote:
Quote:
On Fri, Mar 7, 2008 at 3:16 PM, Mark Knecht <markknecht@gmail.com> wrote:
Quote:
16 0x7ec9a22f DIALOG_DoDialogBox+0xdf() in user32 (0x7dad9528)

Hi Mark, thanks for asking! Sadly, that trace doesn't have
line numbers. Perhaps that info was stripped out
during install; try running the wine that's in the build
directory (if you can).

Dan,
Currently I'm running Wine built from Gentoo portage. All the
default gcc flags either turn off or strip out all this backtrace
info. I tried turning it back on but I'm not a developer and really
don't understand this stuff so I'll need to learn.

I saw on the Wine site that it says the default version of Wine has
this stuff turned on. I suppose that means that if I download the
tarball and build from that then I'll get the info possibly because
the Wine build process doesn't turn it off or strip it out.

If building from WineHQ.org's tarball is more likely to make the
developers happy then I'll give that a try. Please let me know if
that's the best way to go.

cheers,
Mark


Top 
 Post Posted: Fri Mar 07, 2008 6:58 pm 
 
On Fri, Mar 7, 2008 at 3:47 PM, Mark Knecht <markknecht@gmail.com> wrote:
Quote:
If building from WineHQ.org's tarball is more likely to make the
developers happy then I'll give that a try. Please let me know if
that's the best way to go.

Probably. If my resident gentoo guru were here, I
might have better info for you.

You don't even need to install it! Just do
./configure
make depend
make
and then you can use it from that directory, e.g.
./wine notepad


Top 
 Post Posted: Fri Mar 07, 2008 7:41 pm 
 
On 3/7/08, Dan Kegel <dank@kegel.com> wrote:
Quote:
On Fri, Mar 7, 2008 at 3:47 PM, Mark Knecht <markknecht@gmail.com> wrote:
Quote:
If building from WineHQ.org's tarball is more likely to make the
developers happy then I'll give that a try. Please let me know if
that's the best way to go.


Probably. If my resident gentoo guru were here, I
might have better info for you.

You don't even need to install it! Just do
./configure
make depend
make
and then you can use it from that directory, e.g.
./wine notepad



Did you try this? http://www.gentoo.org/proj/en/qa/backtraces.xml


Top 
 Post Posted: Fri Mar 07, 2008 8:24 pm 
 
On Fri, Mar 7, 2008 at 4:40 PM, Charity Abbott <angeliqer@gmail.com> wrote:
Quote:
On 3/7/08, Dan Kegel <dank@kegel.com> wrote:
Quote:
On Fri, Mar 7, 2008 at 3:47 PM, Mark Knecht <markknecht@gmail.com> wrote:
Quote:
If building from WineHQ.org's tarball is more likely to make the
developers happy then I'll give that a try. Please let me know if
that's the best way to go.


Probably. If my resident gentoo guru were here, I
might have better info for you.

You don't even need to install it! Just do
./configure
make depend
make
and then you can use it from that directory, e.g.
./wine notepad



Did you try this? http://www.gentoo.org/proj/en/qa/backtraces.xml


Yes thanks. That's what I was working from to get this far.

For Dan - one other issue came up so I thought I'd bring it here
before I did the new Wine build. Please keep in mind that this machine
is a Gentoo 64-bit machine and Wine, compiled as a 32-bit app, is
running over the top some 32-bit emulation libraries. Those libraries,
as compiled, aren't going to provide any backtrace data. Will this
make any difference or is all we are concerned with is how Wine is
working internally?

Thanks,
Mark


Top 
 Post Posted: Fri Mar 07, 2008 10:17 pm 
 
On Fri, Mar 7, 2008 at 5:24 PM, Mark Knecht <markknecht@gmail.com> wrote:
Quote:
For Dan - one other issue came up so I thought I'd bring it here
before I did the new Wine build. Please keep in mind that this machine
is a Gentoo 64-bit machine and Wine, compiled as a 32-bit app, is
running over the top some 32-bit emulation libraries.

Not emulation libraries. They're plain old 32 bit libraries.

Building 32 bit wine on a 64 bit system is annoying.
I wouldn't bother unless you're quite motivated.

Quote:
Those libraries,
as compiled, aren't going to provide any backtrace data. Will this
make any difference or is all we are concerned with is how Wine is
working internally?

No problem. We don't need symbols there.

Why is it that people run 64 bit operating systems on their
desktops? 99% of them would be happier with 32 bit OS's.
Shrug.
- Dan


Top 
 Post Posted: Fri Mar 07, 2008 10:24 pm 
 
A bit offtopic, but it's mostly because of preference, and 64-bit seems more
lightweight when it comes to multitasking and other kind of operations. At
least that's been my experience, but I keep 32-bit just because it's more
compatible xD (I've had a few issues with wifi and webcam drivers before so
:p)

On Sat, Mar 8, 2008 at 10:47 PM, Dan Kegel <dank@kegel.com> wrote:

Quote:
Why is it that people run 64 bit operating systems on their
desktops? 99% of them would be happier with 32 bit OS's.
Shrug.
- Dan


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.winehq.org/pipermail/wine-us ... chment.htm


Top 
 Post Posted: Sat Mar 08, 2008 12:16 am 
Offline
Moderator
Moderator

Joined: Sat Feb 23, 2008 2:29 pm
Posts: 6605
If you install binaries and then "strip" then (or the installer strips them) then they are no good. You have to either:
1. Tell the installer not to strip Wine binaries when it installs them
2. Install debug package (dunno if it's available with gentoo)
3. Compile Wine yourself and do not install it - run it from the compile dir (as noted above)


Top 
 Post Posted: Sat Mar 08, 2008 8:50 am 
 
According to Gentoo...
Note: Some packages unfortunately handle stripping by themselves,
inside the upstream provided makefiles. This is an error and should be
reported. All packages should leave Portage the task of the stripping
or simply restrict stripping entirely. The main exception to this are
binary packages. They are usually stripped by upstream, outside of
Portage control.

Wine seems to be one of these packages. I tried it myself. However,
they provide winedbg and it is included in the Gentoo package. Did you
try running that?


Top 
 Post Posted: Sat Mar 08, 2008 11:36 am 
Offline
Moderator
Moderator

Joined: Sat Feb 23, 2008 2:29 pm
Posts: 6605
Charity Abbott wrote:
Wine seems to be one of these packages. I tried it myself.

Whatever you are smoking you have to really stop! Wine's install rules do NOT strip binaries. You are welcome to verify
Code:
./configure && make all install


Charity Abbott wrote:
However, they provide winedbg and it is included in the Gentoo package. Did you
try running that?

What winedbg has anything to do with that?! Do you even have a clue what it is?


Top 
 Post Posted: Sat Mar 08, 2008 12:34 pm 
 
On Sat, Mar 8, 2008 at 8:36 AM, vitamin <wineforum-user@winehq.org> wrote:
Quote:
Charity Abbott wrote:
Quote:
Wine seems to be one of these packages. I tried it myself.

Whatever you are smoking you have to really stop! Wine's install rules do NOT strip binaries. You are welcome to verify
Code:
./configure && make all install





Charity Abbott wrote:
Quote:
However, they provide winedbg and it is included in the Gentoo package. Did you
try running that?

What winedbg has anything to do with that?! Do you even have a clue what it is?



Hi guys,
Gee, I wish I would have posted this last night. Maybe it would
have helped keep things more low key.

OK, there seems to have been a new release of Wine on the WinHQ.org
site so I built that last night and did not install it. This morning I
took some time and tried to get better backtrace data. It looks better
to me. A small bit is attached below. Can someone now tell me if this
sort of data is good enough to help before I send the data to
Bugzilla?

I ran Wine this way:

mark@lightning ~/Desktop/Wine-0.9.57 $ ./wine-0.9.57/wine
"D:\setup.exe" &>~mark/Desktop/wine-LH_log.txt

Thanks,
MArk


fixme:wave:wodPlayer_Reset shouldn't have headers left
wine: Unhandled division by zero at address 0x127f:0x00009de9 (thread
0015), starting debugger...
Unhandled exception: divide by zero in 16-bit code (127f:9de9).
In 16 bit mode.
Register dump:
CS:127f SS:12c7 DS:12c7 ES:12c7 FS:0063 GS:006b
IP:9de9 SP:5254 BP:537a FLAGS:0a47( - 00 ROIZP1C)
AX:0a00 BX:000e CX:04a9 DX:048d SI:001a DI:001a
Stack dump:
0x12c7:0x5254: 129f 12c7 6c53 129f 5da2 0001 35f6 128f
0x12c7:0x5264: 35f6 128f 0000 0000 0000 0030 1914 0000
0x12c7:0x5274: 0000 0000 01e8 014d 1668 a10d 1e24 1587
0258: sel=12c7 base=0040e370 limit=000067bf 16-bit rw-
Backtrace:
=>1 0x127f:0x9de9 (0x12c7:0x537a)
2 0x129f:0x5265 (0x12c7:0x538a)
3 0x129f:0x538f (0x12c7:0x53a0)
4 0x129f:0x1c8b (0x12c7:0x53d4)
5 0x129f:0x1833 (0x12c7:0x53ea)
6 0x1287:0x3945 (0x12c7:0x53fe)
7 0x1287:0x3a61 (0x12c7:0x5424)
8 0x1287:0x2e23 (0x12c7:0x5442)
9 0x1287:0x203d (0x12c7:0x5464)
10 0x1287:0x1c57 (0x12c7:0x54b0)
11 0x1287:0x11c7 (0x12c7:0x5504)
12 0x1287:0x1318 (0x12c7:0x551c)
13 0x101f:0x0468 __wine_call_to_16_ret() in kernel32 (0x12c7:0x5556)
14 0x7ee8cb7e K32WOWCallback16Ex+0xce(vpfn16=0x0, dwFlags=<is not
available>, cbArgs=<register ESI not in topmost frame>,
pArgs=0x7e472b60, pdwRetCode=0x7e472894)
[/home/mark/Desktop/Wine-0.9.57/wine-0.9.57/dlls/kernel32/wowthunk.c:636]
in kernel32 (0x7e472858)
15 0x7ed1442e call_window_proc16+0x16e(hwnd=0x5c, msg=0x111,
wParam=0x45b, lParam=<register EDI not in topmost frame>,
result=0x7e47380c, arg=<is not available>)
[/home/mark/Desktop/Wine-0.9.57/wine-0.9.57/dlls/user32/winproc.c:549]
in user32 (0x7e472b98)
16 0x7ed16eac WINPROC_CallProc32ATo16+0x101c(callback=0x7ed142c0,
hwnd=0x1005c, msg=<is not available>, wParam=<is not available>,
lParam=<register ESI not in topmost frame>, result=0x7e47380c,
arg=0x128712f2)
[/home/mark/Desktop/Wine-0.9.57/wine-0.9.57/dlls/user32/winproc.c:2165]
in user32 (0x7e473098)
17 0x7ed1841a call_window_proc_Ato16+0x4a(hwnd=0x1005c, msg=0x111,
wp=0x45b, lp=0x10082, result=0x7e47380c, arg=0x128712f2)
[/home/mark/Desktop/Wine-0.9.57/wine-0.9.57/dlls/user32/winproc.c:567]
in user32 (0x7e4730c8)
18 0x7ed185a1 WINPROC_CallProcWtoA+0x181(callback=0x7ed183d0,
hwnd=0x1005c, msg=0x111, wParam=0x45b, lParam=0x10082,
result=0x7e47380c, arg=0x128712f2)
[/home/mark/Desktop/Wine-0.9.57/wine-0.9.57/dlls/user32/winproc.c:1272]
in user32 (0x7e473768)
19 0x7ed1a8cf WINPROC_call_window+0x1df(hwnd=<register ESI not in
topmost frame>, msg=0x111, wParam=0x45b, lParam=0x10082,
result=0x7e47380c, unicode=0x1, mapping=0x45b)
[/home/mark/Desktop/Wine-0.9.57/wine-0.9.57/dlls/user32/winproc.c:2202]
in user32 (0x7e4737a8)
20 0x7ecdd662 call_window_proc+0xc2(hwnd=<register ESI not in
topmost frame>, msg=0x111, wparam=0x45b, lparam=0x10082, unicode=0x1,
same_thread=0x1, mapping=0x45b)
[/home/mark/Desktop/Wine-0.9.57/wine-0.9.57/dlls/user32/message.c:1615]
in user32 (0x7e473818)


Top 
 Post Posted: Sat Mar 08, 2008 12:57 pm 
 
On Fri, Mar 7, 2008 at 7:17 PM, Dan Kegel <dank@kegel.com> wrote:
Quote:
On Fri, Mar 7, 2008 at 5:24 PM, Mark Knecht <markknecht@gmail.com> wrote:
Quote:
For Dan - one other issue came up so I thought I'd bring it here
before I did the new Wine build. Please keep in mind that this machine
is a Gentoo 64-bit machine and Wine, compiled as a 32-bit app, is
running over the top some 32-bit emulation libraries.

Not emulation libraries. They're plain old 32 bit libraries.

Building 32 bit wine on a 64 bit system is annoying.
I wouldn't bother unless you're quite motivated.


It wasn't any problem to build. make && make depend and it was done.
That said I'm not sure of it's usefulness just yet.

Quote:
Quote:
Those libraries,
as compiled, aren't going to provide any backtrace data. Will this
make any difference or is all we are concerned with is how Wine is
working internally?

No problem. We don't need symbols there.

Why is it that people run 64 bit operating systems on their
desktops? 99% of them would be happier with 32 bit OS's.
Shrug.
- Dan


Actually, if you were to search out all the times I gave an answer to
someone on the audio lists about should they build 32-bit or 64-bit
you will find that I'm 100% in the 32-bit camp.

So, how come this machine is 64-bit? Well, it goes like this. I bought
this machine 3 1/2 years ago. I had two Fedora 32-bit machines at the
time, one desktop and one laptop. I got an offer I couldn't refuse on
the laptop and sold it. My son then needed a machine for school so he
got my old slow desktop. I was left with the (then) fast 3GHz 64-bit
machine that started as an experiment really. It has a 32-bit chroot
(out of date now) which I wanted to make bootable but never got it
working. If I could then I wouldn't run 64-bit myself. Far too many
problems with web media in M$ formats.

Wonder why I forgot about this bug in the first place? For a couple of
years I didn't even think it was worth the effort to run Wine on the
64-bit machine. I figured it wouldn't work. (I'm still not.) I quit
and the last bugs I filed were back in 2005 I think, at least on this
machine.

Wonder why I'm back? Don't know really. Something came up on some
audio list about folks on 64-bit Linux running Wine to use some audio
programs so I figured (right or wrong) that it might be better now to
give Wine a try. However if you think this is pointless let me know
and I'll stop. As far as I can tell Wine works the same for me on this
machine as our other 32-bit Gentoo machines. I don't see any
difference in how well the programs I'd like to run, mostly games,
actually work.

Really the only issue here, for me, is can I help by giving some good
data. If it helps, then great. Mostly I don't want it to be a bother
to anyone, either on this list or the Wine developers. I'd just like
my time to be as useful as it can and if the games ever get fixed all
the better.

Hope that explains,
Mark


Top 
 Post Posted: Sat Mar 08, 2008 1:14 pm 
Offline
Moderator
Moderator

Joined: Sat Feb 23, 2008 2:29 pm
Posts: 6605
Mark Knecht wrote:
This morning I
took some time and tried to get better backtrace data. It looks better
to me. A small bit is attached below. Can someone now tell me if this
sort of data is good enough to help before I send the data to
Bugzilla?


Yes that looks much better.


Top 
 Post Posted: Sat Mar 08, 2008 1:27 pm 
 
On Sat, Mar 8, 2008 at 10:14 AM, vitamin <wineforum-user@winehq.org> wrote:
Quote:
Mark Knecht wrote:
Quote:
This morning I
took some time and tried to get better backtrace data. It looks better
to me. A small bit is attached below. Can someone now tell me if this
sort of data is good enough to help before I send the data to
Bugzilla?


Yes that looks much better.

Yeah, I thought so.

Now, does it not matter that the first 10 lines or so don't have any
info? I guess the lines a bit lower give them enough info to get close
enough. That's the idea anyway?

With your input I'll go ahead and add the whole file to the bug report.

Thanks!

- Mark


Top 
 Post Posted: Sat Mar 08, 2008 1:40 pm 
 
On Sat, Mar 8, 2008 at 10:14 AM, vitamin <wineforum-user@winehq.org> wrote:
Quote:
Quote:
Can someone now tell me if this
sort of data is good enough to help before I send the data to
Bugzilla?

Yes that looks much better.

Yep, the 32 bit stuff has line numbers.

Be sure to attach the log as a file, not inline.

And you should probably also attach a +relay log.
- Dan


Top 
 Post Posted: Sat Mar 08, 2008 1:56 pm 
 
On Sat, Mar 8, 2008 at 11:36 AM, vitamin <wineforum-user@winehq.org> wrote:
Quote:
Charity Abbott wrote:
Quote:
Wine seems to be one of these packages. I tried it myself.

Whatever you are smoking you have to really stop! Wine's install rules do NOT strip binaries. You are welcome to verify
Code:
./configure && make all install



This note was specific to the Gentoo package. Do you run Gentoo? I was
merely verifying what he said earlier about adjusting the make.conf
file in Gentoo to not strip the binaries. It does not work correctly
with wine as documented on the Gentoo site. You get ?? symbols when
running gdb.

Quote:

Charity Abbott wrote:
Quote:
However, they provide winedbg and it is included in the Gentoo package. Did you
try running that?

What winedbg has anything to do with that?! Do you even have a clue what it is?



I found I got actual backtrace data, register dump and stack dump when
I ran winedbg "name_of_app", then typing the finish command. I was
just trying to be helpful. In fact, it looked a lot like the backtrace
data Mark just posted.


Top 
 Post Posted: Sat Mar 08, 2008 2:23 pm 
 
On Sat, Mar 8, 2008 at 10:40 AM, Dan Kegel <dank@kegel.com> wrote:
Quote:
And you should probably also attach a +relay log.
- Dan

Does this mean run it again but use +relay in the command line? If so
could you give the correct format? I just tried this I found in
Google:

WINEDEBUG=+relay ./Wine-0.9.57/wine-0.9.57/wine "D:\setup.exe"
&>~mark/Desktop/wine-LH_log2.txt

but the output file is large, 45K lines. Maybe you want me to use some
-OPTION things to make that smaller?

When I get down around the failure this is what I see:

0015:Call winedos.inport(00000061,00000001) ret=7ee3f94e
0015:Ret winedos.inport() retval=00000020 ret=7ee3f94e
0015:Call winedos.outport(00000061,00000001,00000021) ret=7ee3f7c8
0015:Ret winedos.outport() retval=00000001 ret=7ee3f7c8
0015:Call winedos.outport(00000061,00000001,00000020) ret=7ee3f7c8
0015:Ret winedos.outport() retval=00000000 ret=7ee3f7c8
0015:Call winedos.inport(00000042,00000001) ret=7ee3f94e
0015:Ret winedos.inport() retval=00000091 ret=7ee3f94e
0015:Call winedos.inport(00000042,00000001) ret=7ee3f94e
0015:Ret winedos.inport() retval=000000ff ret=7ee3f94e
0015:Call KERNEL32.UnhandledExceptionFilter(7e470f10) ret=7ef96573
wine: Unhandled division by zero at address 0x127f:0x00009de9 (thread
0015), starting debugger...
0015:Ret KERNEL32.UnhandledExceptionFilter() retval=00000000 ret=7ef96573
Unhandled exception: divide by zero in 16-bit code (127f:9de9).
In 16 bit mode.
Register dump:
CS:127f SS:12c7 DS:12c7 ES:12c7 FS:0063 GS:006b
IP:9de9 SP:5254 BP:537a FLAGS:0a47( - 00 ROIZP1C)
AX:0a00 BX:000e CX:04a9 DX:048d SI:001a DI:001a
Stack dump:
0x12c7:0x5254: 129f 12c7 6c53 129f 5da2 0001 35f6 128f
0x12c7:0x5264: 35f6 128f 0000 0000 0000 0030 1914 0000
0x12c7:0x5274: 0000 0000 01e8 014d fec8 4ef8 1e24 1587
0258: sel=12c7 base=0040e370 limit=000067bf 16-bit rw-
Backtrace:
=>1 0x127f:0x9de9 (0x12c7:0x537a)
2 0x129f:0x5265 (0x12c7:0x538a)
3 0x129f:0x538f (0x12c7:0x53a0)
4 0x129f:0x1c8b (0x12c7:0x53d4)
5 0x129f:0x1833 (0x12c7:0x53ea)
6 0x1287:0x3945 (0x12c7:0x53fe)
7 0x1287:0x3a61 (0x12c7:0x5424)
8 0x1287:0x2e23 (0x12c7:0x5442)
9 0x1287:0x203d (0x12c7:0x5464)
10 0x1287:0x1c57 (0x12c7:0x54b0)
11 0x1287:0x11c7 (0x12c7:0x5504)


Thanks,
Mark


Top 
 Post Posted: Sat Mar 08, 2008 2:29 pm 
 
On Sat, Mar 8, 2008 at 11:22 AM, Mark Knecht <markknecht@gmail.com> wrote:
Quote:
Does this mean run it again but use +relay in the command line?

Yes.

Quote:
If so could you give the correct format? I just tried this I found in
Google:

WINEDEBUG=+relay ./Wine-0.9.57/wine-0.9.57/wine "D:\setup.exe"
&>~mark/Desktop/wine-LH_log2.txt

but the output file is large, 45K lines. Maybe you want me to use some
-OPTION things to make that smaller?

No, you got it right! To make it smaller, compress it, e.g. with gzip.

Quote:
When I get down around the failure this is what I see:

0015:Call winedos.inport(00000061,00000001) ret=7ee3f94e
0015:Ret winedos.inport() retval=00000020 ret=7ee3f94e
0015:Call winedos.outport(00000061,00000001,00000021) ret=7ee3f7c8
0015:Ret winedos.outport() retval=00000001 ret=7ee3f7c8
0015:Call winedos.outport(00000061,00000001,00000020) ret=7ee3f7c8
0015:Ret winedos.outport() retval=00000000 ret=7ee3f7c8
0015:Call winedos.inport(00000042,00000001) ret=7ee3f94e
0015:Ret winedos.inport() retval=00000091 ret=7ee3f94e
0015:Call winedos.inport(00000042,00000001) ret=7ee3f94e
0015:Ret winedos.inport() retval=000000ff ret=7ee3f94e
0015:Call KERNEL32.UnhandledExceptionFilter(7e470f10) ret=7ef96573

wine: Unhandled division by zero at address 0x127f:0x00009de9 (thread
0015), starting debugger...

Getting there. You might want to add +seh to show more info about
the exception. But this is kind of looking like it's going to be hard to
fix, the crash seems to be happening in 16 bit app code.

What app is this? Please give us the link to the bug report when you're done.
- Dan


Top 
 Post Posted: Sat Mar 08, 2008 2:36 pm 
Offline
Level 4
Level 4

Joined: Sun Feb 24, 2008 8:24 pm
Posts: 125
Dan Kegel wrote:
Why is it that people run 64 bit operating systems on their desktops? 99% of them would be happier with 32 bit OS's.
Shrug.
- Dan


64-bit processors? Refusal to live in the past? 100% of other Linux apps working fine in 64-bit? Ability to address all of memory in one segment? Find myself in the 1%? I can't exactly settle on one answer. :p

Sure, I *know* you can come up with a lot of reasons running 32-bit is "better" (or at least, easier for developers and average users), and even show that performance improvements for straight-64-bit are minimal in 'normal' use.

But, the people running 64-bit desktops are helping the developers find problems, and make the apps "bit-agnostic". That in itself has to be worth something.


Top 
 Post Posted: Sat Mar 08, 2008 2:46 pm 
 
On Sat, Mar 8, 2008 at 11:28 AM, Dan Kegel <dank@kegel.com> wrote:
Quote:
On Sat, Mar 8, 2008 at 11:22 AM, Mark Knecht <markknecht@gmail.com> wrote:
Quote:
Does this mean run it again but use +relay in the command line?

Yes.


Quote:
If so could you give the correct format? I just tried this I found in
Google:

WINEDEBUG=+relay ./Wine-0.9.57/wine-0.9.57/wine "D:\setup.exe"
&>~mark/Desktop/wine-LH_log2.txt

but the output file is large, 45K lines. Maybe you want me to use some
-OPTION things to make that smaller?

No, you got it right! To make it smaller, compress it, e.g. with gzip.

Good. I tried it again with quotes around the "+relay" since I missed
that fine point. Didn't change anything much.
Quote:

Quote:
When I get down around the failure this is what I see:

0015:Call winedos.inport(00000061,00000001) ret=7ee3f94e
0015:Ret winedos.inport() retval=00000020 ret=7ee3f94e
0015:Call winedos.outport(00000061,00000001,00000021) ret=7ee3f7c8
0015:Ret winedos.outport() retval=00000001 ret=7ee3f7c8
0015:Call winedos.outport(00000061,00000001,00000020) ret=7ee3f7c8
0015:Ret winedos.outport() retval=00000000 ret=7ee3f7c8
0015:Call winedos.inport(00000042,00000001) ret=7ee3f94e
0015:Ret winedos.inport() retval=00000091 ret=7ee3f94e
0015:Call winedos.inport(00000042,00000001) ret=7ee3f94e
0015:Ret winedos.inport() retval=000000ff ret=7ee3f94e
0015:Call KERNEL32.UnhandledExceptionFilter(7e470f10) ret=7ef96573

wine: Unhandled division by zero at address 0x127f:0x00009de9 (thread
0015), starting debugger...

Getting there. You might want to add +seh to show more info about
the exception. But this is kind of looking like it's going to be hard to
fix, the crash seems to be happening in 16 bit app code.

Yep, it does. That was one of vitamin's comments early on that I think
you nixed at the time. No big deal. Either way it would be good to get
it looked at.

Quote:
What app is this? Please give us the link to the bug report when you're done.
- Dan


The app is an old, old game called Lighthouse:The Dark Being which I
never finished in the old days or running Win 95 or Win ME. It came
out in about 1998 and isn't sold anymore. The item that fails is a
small section of the app that tests the system for compatibility. In
the thread called "CDROM detect failed" a couple of days ago I posted
a small PNG file that showed the part of the app that fails. There are
a number of button you push to check things - OS, graphics, processor,
CDROM, etc. Two fail consistently - the CDROM and the processor.

The best link I have right now is in the bug report:

http://bugs.winehq.org/show_bug.cgi?id=2555

The link above has a download button but you have to be a file planet
member to get it.

There are other links on the web about the game:

http://en.wikipedia.org/wiki/Lighthouse_(computer_game)

It's generally in the Myst genre but harder puzzles to solve, or so I felt.

I'll look at adding +seh, zipping the file and submitting it in the
next hour or so.

Thanks much,
Mark


Top 
 Post Posted: Sat Mar 08, 2008 4:39 pm 
Offline
Moderator
Moderator

Joined: Sat Feb 23, 2008 2:29 pm
Posts: 6605
Mark Knecht wrote:
The app is an old, old game called Lighthouse:The Dark Being which I
never finished in the old days or running Win 95 or Win ME. It came
out in about 1998 and isn't sold anymore. The item that fails is a
small section of the app that tests the system for compatibility. In
the thread called "CDROM detect failed" a couple of days ago I posted
a small PNG file that showed the part of the app that fails. There are
a number of button you push to check things - OS, graphics, processor,
CDROM, etc. Two fail consistently - the CDROM and the processor.


Does it even work on win2k/winxp? Have you tried first? There are more and more things that Wine does the winNT way and not win9x way. So if you have an app that worked on win9x only - most likely it won't work on Wine.


Top 
 Post Posted: Sat Mar 08, 2008 5:00 pm 
 
On Sat, Mar 8, 2008 at 1:39 PM, vitamin <wineforum-user@winehq.org> wrote:
Quote:
Mark Knecht wrote:
Quote:
The app is an old, old game called Lighthouse:The Dark Being which I
never finished in the old days or running Win 95 or Win ME. It came
out in about 1998 and isn't sold anymore. The item that fails is a
small section of the app that tests the system for compatibility. In
the thread called "CDROM detect failed" a couple of days ago I posted
a small PNG file that showed the part of the app that fails. There are
a number of button you push to check things - OS, graphics, processor,
CDROM, etc. Two fail consistently - the CDROM and the processor.


Does it even work on win2k/winxp? Have you tried first? There are more and more things that Wine does the winNT way and not win9x way. So if you have an app that worked on win9x only - most likely it won't work on Wine.


I don't load games on my Windows machine anymore. I use Windows to
trade stocks and absolutely nothing else. If I cannot play it in wine
then I won't bother.

Please remember that I've said earlier that the game itself seems to
work fine, or at least well enough for me to install it and start
playing. I don't know if I'll get to the end successfully in Wine but
at least the game itself works well enough to get started. The only
part that I'm filing a report on is the part of the install process
that tests the system for hardware compatibility, and even in that
part only two parts seem to fail - the part that tests the CDROM and
the part that tests the CPU/OS. Even the OS part passes and it's only
the CPU part that the test says fails.

So, I completely understand that wine may never work completely for
all old Windows programs but if I don't report it then it never gets
fixed, right?

If there is a way for me to get even more in depth data I'm happy to
do that. It will take time but I figure why not? I have a lot of old
games that would be fun to revisit. I was thinking that I may start
repeating the process we're going through on Lighthouse on all my old
games jsut to see what works and what doesn't. Isn't that what we're
supposed ot do?

Thanks,
Mark


Top 
 Post Posted: Mon Mar 10, 2008 4:48 am 
 
Dan Kegel wrote:
Quote:
On Fri, Mar 7, 2008 at 5:24 PM, Mark Knecht <markknecht@gmail.com> wrote:

Quote:
For Dan - one other issue came up so I thought I'd bring it here
before I did the new Wine build. Please keep in mind that this machine
is a Gentoo 64-bit machine and Wine, compiled as a 32-bit app, is
running over the top some 32-bit emulation libraries.


Not emulation libraries. They're plain old 32 bit libraries.

Building 32 bit wine on a 64 bit system is annoying.
I wouldn't bother unless you're quite motivated.


Quote:
Those libraries,
as compiled, aren't going to provide any backtrace data. Will this
make any difference or is all we are concerned with is how Wine is
working internally?


No problem. We don't need symbols there.

Why is it that people run 64 bit operating systems on their
desktops? 99% of them would be happier with 32 bit OS's.
Shrug.
- Dan



Funny, my view is the exact opposite. I first used 64 bit on a Dec Alpha
in about 1993. I have been wondering ever since why anybody would want
to cling to 32 bit. Recently I have been puzzled as to why anybody would
want to run a 32 bit opsys on 64 bit hardware. I think they just sense a
lack of commitment from Microsoft. Incidentally, I heard that Microsoft
had a 64 bit version of NT (an early one 3.1 or 3.5) for the Dec Alpha
but never released it. They released a 32 bit version for the Alpha - so
everybody ran Tru64 unix instead. The attraction of 64 bit is address
space more than large physical memory. If you are mapping large files
the address space issue is significant. A windows 32 bit application can
get about 1.5GB of usable address space in an application and it is not
enough. I had better declare my bias; I implement an APL interpreter. A
significant number of my users are bouncing off address space
restrictions and are being held back because their users are constrained
to use 32 bit windows as a platform.

Geoff Streeter

Geoff Streeter


Top 
 Post Posted: Mon Mar 10, 2008 10:52 am 
 
Geoff Streeter <geoff@dyalog.com> wrote:
Quote:
Funny, my view is the exact opposite. I first used 64 bit on a Dec Alpha
in about 1993. I have been wondering ever since why anybody would want
to cling to 32 bit.

Abstractly, I agree. But there are so many gotchas and so little
payoff for desktop users in the switch to 64 bits that it seems
premature, at least for people who don't want to help ferret out
the remaining problems.

Quote:
I had better declare my bias; I implement an APL interpreter. A
significant number of my users are bouncing off address space
restrictions and are being held back because their users are constrained
to use 32 bit windows as a platform.

Sure, your users have a real reason to go 64 bits. The
average desktop user doesn't.
- Dan


Top 
Display posts from previous:  Sort by  
 
 Page 1 of 2 [ 28 posts ] Go to page 1, 2  Next




Board index » WineHQ » Wine Help


Who is online

Users browsing this forum: Google [Bot] and 13 guests

 
 

 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: