May 2003 - Wine-Devel - list.winehq.org

wine debugger and Agent by Forte Inc

by schuetzen

running Forte Agent in Wine. works GREAT! except that almost every time I send a message or reply from the s/w, the Wine debugger runs and I have to shut the software down and then restart it. this is aggravating when I am running a dozen elists which are moderated. the message in the end of the debug script is Unhandled exception: divide by zero in 32 bit code (0X0043e44), In 32-bit mode. 0X0043e44 (agent.exe.(a)ENUMERATEACTIVEWNDS$QP6HWND_P (wrapping line here) 9TENUMINFO+0xa9b4 in C:\Program Files\Agent\agent.exe): div1 0x4(%ebx),%eax ===== Agent was downloaded from the forte.inc website and then installed into Linux (thisis a new and fresh install on a new hard drive) with Suse starting up Wine and installing Wine and then installing Agent. all automatically. really need help with this -- powered by Linux, Suse 8.2 Pro + Agent under Wine emulator Charles L Hamilton, Houston, TX chasm @ texas. net www.schuetzen.net

May 2, 2003

Re: With-* test in configure (was: wine and RedHat 9)

by Rob Hughes

On Fri, 2003-05-02 at 01:53, Shachar Shemesh wrote: > Rob Hughes wrote: > > >Here's a screen shot from a debug message. I'm assuming this uses the > >standard wine language code? > > > >On Thu, 2003-05-01 at 15:54, Sylvain Petreolle wrote: > > > > > >>Huh ? English is the default lang for wine, it shouldnt happen. > >>Could you give a precise example ? Im using fr_FR.UTF-8 on RH9. > >> > >> > >> > >>>Most of the pop up dialogs are showing this, but sometimes it's only > >>>one > >>>button or the other. LANG is set to > >>> > >>>LANG=LANG="en_US.UTF-8", which is the default in RH 8 and 9. > >>> > >>>Thanks, > >>>Rob > >>> > >>> > >>> > I'm thinking of three possible explanations for this: > > 1. Tracing the specific dialog Rob showed, it calls "MessageBoxA", > which calls "MessageBoxExA" with a language identifier > "LANG_DEFAULT". According to > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winu… > the langid parameter is "reserved". Can anyone confirm that there > is any version of Windows that uses it? > 2. Even if it did what it was supposed to do, shouldn't the paramter > at windows/msgbox.c, line 347, say > "MAKELANG(LANG_NEUTRAL,SUBLANG_DEFAULT)" instead of "LANG_DEFAULT"? > 3. The English resource don't have "SUBLANG_DEFAULT" for something > (does not appear to be the case in latest CVS). > > Rob - what version of Wine are you using? > Also, can you please paste here the output of the command "locale"? I'm running CVS from this past Sunday. Locale output is: LANG=en_US.UTF-8 LC_CTYPE="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_PAPER="en_US.UTF-8" LC_NAME="en_US.UTF-8" LC_ADDRESS="en_US.UTF-8" LC_TELEPHONE="en_US.UTF-8" LC_MEASUREMENT="en_US.UTF-8" LC_IDENTIFICATION="en_US.UTF-8" LC_ALL=

May 2, 2003

Re: Avoid non-portable signal(SIGCHLD, SIG_IGN)

by Gerald Pfeifer

On Wed, 30 Apr 2003, Joerg Wunsch wrote: >> #4 0x5c074f09 in getcwd () from /usr/lib/libc.so.4 > Is getcwd() supposed to cause a SIGSYS at all? > > OTOH, that failing dlsym() syscall could be related to all this... I > don't know why that complicated dlsym() is used, but maybe since > sigaction() is now invoked directly before, the run-time loader has > already loaded it from libc.so before. Maybe Alexandre can shed some > light on how that's supposed to work. It seems someone (Alexandre?) has fixed this; at least, now everything seems to work fine again on FreeBSD 4.8 Thanks! Gerald -- Gerald "Jerry" pfeifer(a)dbai.tuwien.ac.at http://www.pfeifer.com/gerald/

May 2, 2003

Re: New metabugs

by hatky

--- Mike Hearn <m.hearn(a)signal.qinetiq.com> wrote: > On Fri, 2003-05-02 at 08:47, hatky wrote: > > Ok, with you permission I like to get this subject > > changed a bit to clearing bugzilla. > > > > I noticed there are plenty of bugs and little > activity > > on any of then many of them look outdated. > > Yeah, this is a problem for all bugzillas. About a > month or two ago a > few of us went through and cleaned some out. Needs > doing more often > really though. > > > So I would like Step One to be getting all the > bugs > > that there last comment was before 6 months or > more > > commented as please test it again or we will close > it > > in the next 30. > > This sounds like a good idea. We've done it before, > but it takes time to > track them all. Can't we do automaticly? I am pretty sure there can be an sql select that can get that then we need to feel a form... I realy think I could have a php file that does that if I hade the table stracture ... Then we can run it dayly as a cron job and no bug will be really left out to die (I am only talking about the traking prosses here) > > > I really hope you agree with me about that becouse > > with so many open bug I think most developer DO > NOT > > want to trak the bugzilla any more... > > Well, I know I mostly go by the wine-bugs mailing > list, but it does make > bugs easy to forget about. Remember though that > often people just don't > know the answer..... I undertend that but if you know of a bug that says it gets into a race condition and you see in wine-cvs that a patch aginst race conditions have been aplied even if you are not sure that that the same race condition asking the user to test it again can be helpfool, better then leaving a bug with the last test some where on 2001 or earlier with no other comments... > > > Secound Step I would want to do is getting the > bugs > > into some categories so it will be easy for > developer > > to track the bugs that intrest them > > This idea I'm not so sure about. If somebody is > interested in working on > games, then they can fire up games they actually own > and start fixing > bugs. That why I rather have big meta bugs and then the errors in them as sub bugs that way: 1.If you are trying to fix problem X you can locate a few testcases that would help you ensure you solved it right. 2.If you fix problem y we can tell to all users with games that have problem y we are a step closer to running there game (game or app or any other program) 3.You can see with function that is still missing is most needed, I was thinking it would probebly be usefull for people like workers of codewavers but would you rather fix a problem with one program or a problem you know make 15 programs not work? I personaly sould like to sort my prioritys on the problems that block the most programs (I am making sence right?) > Unfortunately Wine is not yet at the stage > where people find it > hard to locate bugs :( That would mean we could drop bugzilla all toghter (I am nither aginst nor for) but as long as it's up I think we sould maintain the bugs in it as it was ment to be. > > > btw just to understend this is a meta bug of > getting > > game x to work and under it all the uniplemented > > or/and broken stuff ok? > > I think these things are better done when somebody > with drive says "I'm > going to make game X work" and then goes ahead and > solves them all - the > chances of finding 2 or 3 people all with that game > and all with that > drive/level of skill is fairly rare, they all work > on different games. I was thinking about bugzilla as being for both users and developers so when that time comes where deleoper1 has all the program he owns working (hopfully soon ;-) optimistic ha?) he could help fixing programs he does not own, that a user reportes an with bugzilla getting the developer to fix and the user to test.... (Besides why sould a developer waist his/her time testing every feather of a big program? We can let users do it and gain a little more programming time) > > > The last step (and an importent one) would be to > try > > keep the traking a live by insreting both > developers > > and users to look at them and keep updating them. > > If nobody knows what causes a bug, or the bug is > "implement feature X" > then no amount of tracking will get the work done > quicker. It basically > boils down to a terminal lack of manpower. I do agree that if no one know why that happened then it is a problem but even so it sould be tested again after a few months for a by mistake fix :) It is know we lack in man power thats they I say we use bigzilla get let users do testing insted of developers, and the more bugs will be solved the more users will join and the more bugs will be up to date the more users will use bugzilla and the more users wine has the more news it will get and more new developers that will solve more bugs. > > > Do you agree with anything I said so far or am I > just > > talking newbee crap? > > It's good you're thinking about these things, but > experience with > bugzillas tells me that especially for a project > like Wine, while it can > be very useful to track odd bugs/regressions etc, > for more general > things it's not so useful. Do you want to make a defintion of what bugs we sould open and track and what sould not get into bugzilla at all? > > thanks -mike > > -- > Mike Hearn <m.hearn(a)signal.qinetiq.com> > QinetiQ - Malvern Technology Center > Hatky. __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com

May 2, 2003

Re: New metabugs

by Mike Hearn

On Fri, 2003-05-02 at 08:47, hatky wrote: > Ok, with you permission I like to get this subject > changed a bit to clearing bugzilla. > > I noticed there are plenty of bugs and little activity > on any of then many of them look outdated. Yeah, this is a problem for all bugzillas. About a month or two ago a few of us went through and cleaned some out. Needs doing more often really though. > So I would like Step One to be getting all the bugs > that there last comment was before 6 months or more > commented as please test it again or we will close it > in the next 30. This sounds like a good idea. We've done it before, but it takes time to track them all. > I really hope you agree with me about that becouse > with so many open bug I think most developer DO NOT > want to trak the bugzilla any more... Well, I know I mostly go by the wine-bugs mailing list, but it does make bugs easy to forget about. Remember though that often people just don't know the answer..... > Secound Step I would want to do is getting the bugs > into some categories so it will be easy for developer > to track the bugs that intrest them This idea I'm not so sure about. If somebody is interested in working on games, then they can fire up games they actually own and start fixing bugs. Unfortunately Wine is not yet at the stage where people find it hard to locate bugs :( > btw just to understend this is a meta bug of getting > game x to work and under it all the uniplemented > or/and broken stuff ok? I think these things are better done when somebody with drive says "I'm going to make game X work" and then goes ahead and solves them all - the chances of finding 2 or 3 people all with that game and all with that drive/level of skill is fairly rare, they all work on different games. > The last step (and an importent one) would be to try > keep the traking a live by insreting both developers > and users to look at them and keep updating them. If nobody knows what causes a bug, or the bug is "implement feature X" then no amount of tracking will get the work done quicker. It basically boils down to a terminal lack of manpower. > Do you agree with anything I said so far or am I just > talking newbee crap? It's good you're thinking about these things, but experience with bugzillas tells me that especially for a project like Wine, while it can be very useful to track odd bugs/regressions etc, for more general things it's not so useful. thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

May 2, 2003

Re: New metabugs

by hatky

Ok so mybe the fix-me/stub/unimplemented bugs category is a really bad idea but we are having diffrent opinions on the more general idea of using metabugs as categories... Hatky. --- Mike Hearn <m.hearn(a)signal.qinetiq.com> wrote: > > fix-me/stub/unimplemented bugs > > application bugs > > and misc bugs > > I have to agree with Dimi, sorry. Do you realise > just how many of these > damn things there are? Grep the source, there are > easily thousands, many > of which are harmless, or are just chatter about > functionality we've > known has been missing for years. There's no need > for a bug about the > lack of a richedit control in bugzilla, we're all > aware of this. > > -- > Mike Hearn <m.hearn(a)signal.qinetiq.com> > QinetiQ - Malvern Technology Center > __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com

May 2, 2003

Re: New metabugs

by hatky

Ok, with you permission I like to get this subject changed a bit to clearing bugzilla. I noticed there are plenty of bugs and little activity on any of then many of them look outdated. So I would like Step One to be getting all the bugs that there last comment was before 6 months or more commented as please test it again or we will close it in the next 30. I really hope you agree with me about that becouse with so many open bug I think most developer DO NOT want to trak the bugzilla any more... Secound Step I would want to do is getting the bugs into some categories so it will be easy for developer to track the bugs that intrest them thats where I was going with my meta bugs becouse I for instence what to know about every bug that is realated to games and see if I can confirm it and/or help solving it, as you do not seem to like my idea of using meta bugs for this how would you like to see this beeing done? btw just to understend this is a meta bug of getting game x to work and under it all the uniplemented or/and broken stuff ok? The last step (and an importent one) would be to try keep the traking a live by insreting both developers and users to look at them and keep updating them. Do you agree with anything I said so far or am I just talking newbee crap? Hatky. __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com

May 2, 2003

Re: New metabugs

by Mike Hearn

> fix-me/stub/unimplemented bugs > application bugs > and misc bugs I have to agree with Dimi, sorry. Do you realise just how many of these damn things there are? Grep the source, there are easily thousands, many of which are harmless, or are just chatter about functionality we've known has been missing for years. There's no need for a bug about the lack of a richedit control in bugzilla, we're all aware of this. -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

May 2, 2003

Re: Unhandled exceptions after XOver Office uninstall

by Mike Hearn

Well, you need to compile Wine using --with-nptl at the moment, otherwise you will get strange threading related errors on any glibc 2.3.x system. You can get RH9 rpms from newrpms.sunsite.dk Could we put some info about this on the front page for a while? I'd write a patch myself but no CVS access at work and I don't have lostwages checked out. I must answer questions about this every single day on various support forums at the moment, it needs to be made crystal clear how to install Wine on the new systems until Alexandre gets the runtime detection code in. thanks -mike On Thu, 2003-05-01 at 20:50, Andrew Rechenberg wrote: > I've just uninstalled Crossover Office with the .unintall script in > /opt/cxoffice and now my other wine installation gives me unhandled > exception errors when trying to start any application. > > My other installation worked just fine before I uninstalled Crossover > Office and it works just fine on my workstation at home without > Crossover so I believe that the Crossover uninstallation FUBAR'ed > something on my workstation here. > > I'm not a guru at developing but I tried to use gdb to see what's > happening and here is what I've done. > > $ gdb wine > (gdb) run regedit > Starting program: /usr/bin/wine regedit > (no debugging symbols found)...(no debugging symbols found)...(no > debugging symbols found)... > (no debugging symbols found)...(no debugging symbols found)...(no > debugging symbols found)... > (no debugging symbols found)...(no debugging symbols found)...[New > Thread 16384 (LWP 2620)] > (no debugging symbols found)... > (no debugging symbols found)...(no debugging symbols found)...(no > debugging symbols found)... > (no debugging symbols found)...(no debugging symbols found)...(no > debugging symbols found)... > (no debugging symbols found)...(no debugging symbols found)...(no > debugging symbols found)... > (no debugging symbols found)...(no debugging symbols found)...(no > debugging symbols found)... > (no debugging symbols found)...(no debugging symbols found)...(no > debugging symbols found)... > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 16384 (LWP 2620)] > 0x4037580e in __pthread_internal_tsd_get () from /lib/libpthread.so.0 > (gdb) bt > #0 0x4037580e in __pthread_internal_tsd_get () from > /lib/libpthread.so.0 > #1 0x400ac1ff in calloc () from /lib/libc.so.6 > #2 0x400de596 in opendir () from /lib/libc.so.6 > #3 0x401cdcb7 in DOSFS_ToDosFCBFormat () from > //usr/lib/wine/wine/ntdll.dll.so > #4 0x401cde33 in DOSFS_ToDosFCBFormat () from > //usr/lib/wine/wine/ntdll.dll.so > #5 0x401ce6af in DOSFS_FindUnixName () from > //usr/lib/wine/wine/ntdll.dll.so > #6 0x401cf691 in DOSFS_GetFullName () from > //usr/lib/wine/wine/ntdll.dll.so > #7 0x401cbff4 in RemoveDirectoryA () from > //usr/lib/wine/wine/ntdll.dll.so > #8 0x401cc4ee in DIR_SearchPath () from > //usr/lib/wine/wine/ntdll.dll.so > #9 0x401cc6e5 in SearchPathW () from //usr/lib/wine/wine/ntdll.dll.so > #10 0x401cca20 in SearchPathA () from //usr/lib/wine/wine/ntdll.dll.so > #11 0x40237ecc in LdrGetProcedureAddress () from > //usr/lib/wine/wine/ntdll.dll.so > #12 0x40236bcc in _aullrem () from //usr/lib/wine/wine/ntdll.dll.so > #13 0x40236fa8 in PE_fixup_imports () from > //usr/lib/wine/wine/ntdll.dll.so > #14 0x401ee337 in PE_CreateModule () from > //usr/lib/wine/wine/ntdll.dll.so > #15 0x402228e6 in PROCESS_CallUserSignalProc () from > //usr/lib/wine/wine/ntdll.dll.so > #16 0x40226c36 in SYSDEPS_SetCurThread () from > //usr/lib/wine/wine/ntdll.dll.so > > I thought it might be a corruption in my libc so I booted to runlevel 1 > and reinstalled my glibc but that did help. > > Does anyone have any ideas? Please CC me as I'm not subscribed to the > lists. > > Red Hat 9 > glibc-2.3.2-27.9 > wine RPM based on CVS as of 20030428 > Crossover Office 2.0.0 (no longer installed) > > Thanks, > Andy. > -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

May 2, 2003

Re: With-* test in configure (was: wine and RedHat 9)

by Shachar Shemesh

Rob Hughes wrote: >Here's a screen shot from a debug message. I'm assuming this uses the >standard wine language code? > >On Thu, 2003-05-01 at 15:54, Sylvain Petreolle wrote: > > >>Huh ? English is the default lang for wine, it shouldnt happen. >>Could you give a precise example ? Im using fr_FR.UTF-8 on RH9. >> >> >> >>>Most of the pop up dialogs are showing this, but sometimes it's only >>>one >>>button or the other. LANG is set to >>> >>>LANG=LANG="en_US.UTF-8", which is the default in RH 8 and 9. >>> >>>Thanks, >>>Rob >>> >>> >>> I'm thinking of three possible explanations for this: 1. Tracing the specific dialog Rob showed, it calls "MessageBoxA", which calls "MessageBoxExA" with a language identifier "LANG_DEFAULT". According to http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winu… the langid parameter is "reserved". Can anyone confirm that there is any version of Windows that uses it? 2. Even if it did what it was supposed to do, shouldn't the paramter at windows/msgbox.c, line 347, say "MAKELANG(LANG_NEUTRAL,SUBLANG_DEFAULT)" instead of "LANG_DEFAULT"? 3. The English resource don't have "SUBLANG_DEFAULT" for something (does not appear to be the case in latest CVS). Rob - what version of Wine are you using? Also, can you please paste here the output of the command "locale"? -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/

May 2, 2003