On 11 February 2013 01:55, Gediminas Jakutis wrote:
> I tried every idea I could muster on how to get a "pure" log of the
> game. Not a single one turned out to be effective.
> I am all out of ideas now. So if anyone had to deal with this and
> found a satisfactory solution, please enlighten me.
>
Actually, to enable attach, I had to make ptrace more permissive:
https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#ptrace_Protection
by doing "echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope"
To run it under eclipse I had to choose Traditional Attach to process
instead of DSF.
On
Attach works. Thanks!
So, you didn't try to build wine? Installed wine also works for me.
On Sat, Jul 07, 2012 at 01:25:12PM +0300, John Yani wrote:
> I tried "WINELOADER=./wine winedbg --gdb notepad"
>
> And its output is the same as "./wine winedbg --gdb notepad"
Well, i have a installed wine... but doing this there:
wine winedbg.exe --gdb notepad.exe
0042:0043: create process 'C
Maybe it's because I'm building on chrooted Ubuntu x32 and run on Ubuntu x64?
I tried "WINELOADER=./wine winedbg --gdb notepad"
And its output is the same as "./wine winedbg --gdb notepad"
Unfortunately, it doesn't work:
./wine winedbg --gdb notepad.exe
err:module:LdrInitializeThunk Main exe initialization for
L"C:\\windows\\system32\\notepad.exe" failed, status c022
0023:0024: create process ''/0x1106c0 @0x7ebe233c (0<0>)
fixme:dbghelp:EnumerateLoadedModulesW64 If this happens,
On Sat, Jul 07, 2012 at 01:11:42PM +0300, John Yani wrote:
> Did you mean './wine winedbg --gdb notepad'? Because I can't find winedbg
> binary.
This would be the same. There usually is a "winedbg" wrapper installed
that does the same, but for all purposes its the same thing.
Ciao, Marcus
Did you mean './wine winedbg --gdb notepad'? Because I can't find winedbg
binary.
On Sat, Jul 07, 2012 at 12:17:00AM +0300, John Yani wrote:
> I tried to run wine under gdb and failed. Using multiprocess gdb I
> endup with weird trace:
>
> 0xf7ffd430
> 0x7bc846f9
> 0x7bc8480f
> 0x7bc84855
> 0x7bc42a94
> 0x7bc433b1
> 0x7b8772f7
> 0x7ebab89b
> 0x7b
OK, thanks for your help.
I'll try this when I'll be back to home.
RB
- Mail original -
De: "Frédéric Delanoy"
À: rolan...@free.fr
Cc: "Juan Lang" , wine-devel@winehq.org
Envoyé: Mardi 20 Décembre 2011 12:28:57
Objet: Re: Debugging Wine with Lightroom 3.5
On Tue, Dec 20, 2011 at 10:04, wrote:
>
> Yes, I'm that kind of person (I'm the developer of Xfe and TexMaths) but I've
> seen the +relay logs logs and they are indeed very huge, even for me!
> RB
What you can do to reduce/manage the log size:
1. Launch any application (without logging), e.g. n
Yes, I'm that kind of person (I'm the developer of Xfe and TexMaths) but I've
seen the +relay logs logs and they are indeed very huge, even for me!
RB
- Mail original -
De: "Juan Lang"
À: "Roland Baudin"
Cc: "Wine Devel"
Envoyé:
Hi Roland,
On Sun, Dec 18, 2011 at 6:46 AM, Roland Baudin wrote:
> Yes, I suspected such a mechanism. Now if I understand well I have to find
> which one is the "builtin mechanism" and which one is the "fallback
> mechanism".
> Is there some documentation around about the differences between Vist
Yes, I suspected such a mechanism. Now if I understand well I have to
find which one is the "builtin mechanism" and which one is the "fallback
mechanism".
Is there some documentation around about the differences between Vista
and XP?
Anyway, thanks for your help...
RB
Le 18/12/2011 13:40, Jo
Replying, also including the wine-devel list,
On 12/17/2011 05:15 PM, Roland Baudin wrote:
Hi,
thanks for the answer.
What do you mean by "a different execution path"?
RB
The application might decide to execute different code given the Vista
settings.
It may have a preferred execution path u
It's possible the application is choosing a different execution path,
using Vista-specific features.
This could be an explanation for the differences you are seeing.
HTH,
Joris
Le 12/04/2011 22:50, joed...@winedev1.nospam.homeip.net a écrit :
I was taking a look at
http://wiki.jswindle.com/index.php/Debugging_Wine
to see how to debug wine with gdb,
and there was reference to starting up gdb using wine-pthread, but I see no
such executable now.
I can attach gdb after i
Le 24/09/2010 05:12, Peter Urbanec a écrit :
On 24/09/10 06:43, Eric Pouech wrote:
sure send me the .exe+pdb (+source) I'll have a look at it
Source and binaries sent to Eric in private, so that the list isn't
polluted with megabytes of binaries. If anyone else is interested in
having a co
On 24/09/10 06:43, Eric Pouech wrote:
sure send me the .exe+pdb (+source) I'll have a look at it
Source and binaries sent to Eric in private, so that the list isn't
polluted with megabytes of binaries. If anyone else is interested in
having a copy, please let me know and I'll forward it in p
I'm happy to provide test source code, 64-bit and 32-bit binaries and
matching PDB files, if anyone is interested in looking at the issue.
sure send me the .exe+pdb (+source) I'll have a look at it
I only tested winedbg on 64bit with gcc
A+
--
Eric Pouech
"The problem with designing something
lto:winehq@urbanec.net]
Sent: Thursday, September 23, 2010 10:05 AM
To: wine-devel@winehq.org
Subject: Re: Debugging 64-bit Wine Apps with winedbg
On 23/09/10 06:51, Tom Grubbe wrote:
> problem seems to be getting any kind of stack trace information from
> the 64-bit winedbg. This used t
On 23/09/10 06:51, Tom Grubbe wrote:
problem seems to be getting any kind of stack trace information from
the 64-bit winedbg. This used to work with the 32-bit version of winedbg.
I can confirm that wine64 winedbg can not produce valid backtraces for
multi-threaded programs (.exe + .pdb) gen
Hi,
I'm not a winedbg expert but I think your mis-using it.
As it's your software, you can compile it from source and add debug info.
I know Visual Studio can create .pdb files but I don't know if winedbg
can use it.
Personally, I'm using gcc mingw with -g and that perfectly works.
The easies
Am 18.10.2009 um 16:24 schrieb Warren Dumortier:
I don't think it's worth to be tested, because if Xfire doesn't
crash (simply by not interacting with it) games are detected.
However i will try it, who knows! ;)
An easier way to test is probably to disable Xfire In-Game, if you
find out how
Am 18.10.2009 um 15:02 schrieb Warren Dumortier:
Xfire was working until version 1.104, but since then it crashed on
every Wine version, so the Xfire update broke it under Wine.
Here's the problem:
Xfire crashes every time you interact with it's GUI, well most of
the time...
When using the
> I just would try to use Kdevelop, but i dont know if it will work.
>
Actually KDevelop works. I created a new empty project and Imported the
whole git repository and
I chose to use wine's custom MakeFile and configure files. I'm not able
though to start the debug properly
but I'm working on it.
Alexandros Dermenakis schrieb:
Hi,
I would like some help about which tools to use for editing code, searching
through the source files etc. also, is there a way to import all the source
code in Kdevelop?
thanks
I mostly edit the files with Geany(geany.org), but thats a matter of taste.
On Sun, Aug 9, 2009 at 10:50 PM, Alexandros
Dermenakis wrote:
> Hi,
>
> I would like some help about which tools to use for editing code, searching
> through the source files etc. also, is there a way to import all the source
> code in Kdevelop?
To get the source:
http://wiki.winehq.org/GitWine
f
Am 10.09.2008 um 17:32 schrieb Stefan Dösinger:
> You can attach any debugger to a Win32 process running in Wine. This
> includes Linux debuggers like gdb, [...]
As I didn't find hints on how to do this I tried myself:
** First, start gdb in the C: directory
[EMAIL PROTECTED]:/otherubuntu/home
On Wednesday 10 September 2008 10:44:09 pm Damjan Jovanovic wrote:
> For example applications don't expect to see pointers into the upper
> 1-2 GB of the 4 GB virtual memory address space because on Windows the
> kernel's memory is mapped there. But, ld-linux.so.2 could load
> libraries there, incl
On Wed, Sep 10, 2008 at 8:17 PM, <[EMAIL PROTECTED]> wrote:
> Question :
> Why does wine have to allocate all its memory at startup? re... the issue
> that is causing the ATI drivers to have such
> a fuss why not just allocate as needed? or have the ability (if its not
> there already) to sp
dbghelp supports both linux debug formats (stabs, dwarf) as well as
microsoft's one
so any debugger using dbghelp as it's debug info provide should debug
with all bells & whistles native & builtin applications
I had some success with windbg (with a an 'e' between n & d ;-)
unfortunately, http://
ubject: RE: Debugging Wine thoughts
You can
attach any debugger to a Win32 process running in Wine. This includes Linux
debuggers like gdb, or any graphical frontends, as well as Windows debuggers
like visual studio. If you built wine from source, the Linux debuggers will s
You can attach any debugger to a Win32 process running in Wine. This
includes Linux debuggers like gdb, or any graphical frontends, as well as
Windows debuggers like visual studio. If you built wine from source, the
Linux debuggers will see the Wine source. Probably they can also read the
Windows a
On Sep 8, 2008, at 9:36 PM, Dan Kegel wrote:
> Kevin K wrote:
>> Is winedbg the only method of debugging applications being
>> developed for Windows on Wine?
>>
>> For instance, assume a program developed with Visual Studio
>> in C or C++, and I needed to debug it on Linux?
>
> If winedbg doesn't
Kevin K wrote:
> Is winedbg the only method of debugging applications being
> developed for Windows on Wine?
>
> For instance, assume a program developed with Visual Studio
> in C or C++, and I needed to debug it on Linux?
If winedbg doesn't work for you, we should fix it. Same
goes for other de
> You change the registry with: regedit (wine provide an own
> implementation)
>
> Patches are welcome.
>
> The source of the website is managed with git:
> http://source.winehq.org/git/website.git (templates/en/*)
No time for doing that. However, here's a patch which improves the
wording a bit
On Fr, 2008-08-08 at 16:51 +0200, Werner LEMBERG wrote:
>
> Investigate the RelayInclude and RelayExclude string values in
> [HKCU\Software\Wine\Debug] if you're being overwhelmed by certain
> functions. [...]
>
> I suppose this is a registry entry, right?
Yes. HKCU (or HCU) is: HKEY_CUR
> Glad to hear that you have sorted out the problem with a new version
> of the application. I think the general rule is that if wine
> doesn't provide some component (such as mfc and vc++ 80), using
> winetricks to install the additional components is preferred over
> installing application's bu
Juan Lang wrote:
>> Ok when I put +relay on I get alot of other stuff I am not looking for...
>
> Sure. Some Windows APIs call other Windows APIs. +relay almost
> always produces too much information, but guessing which debug channel
> you really want is hard. Sometimes you have to read the rel
> Ok when I put +relay on I get alot of other stuff I am not looking for...
Sure. Some Windows APIs call other Windows APIs. +relay almost
always produces too much information, but guessing which debug channel
you really want is hard. Sometimes you have to read the relay channel
to guess which
Juan Lang wrote:
>> So is there any way to output just the win32 API calls and no wine
>> information.
>
> That's precisely what +relay does. I'm not sure what you mean by "no
> wine information."
> --Juan
Ok when I put +relay on I get alot of other stuff I am not looking for...
So what I am loo
> So is there any way to output just the win32 API calls and no wine
> information.
That's precisely what +relay does. I'm not sure what you mean by "no
wine information."
--Juan
Austin English wrote:
> On Wed, Jul 2, 2008 at 10:29 PM, Chris Ahrendt <[EMAIL PROTECTED]> wrote:
>> Is there a way within wine or wine debug to tell it to output just the
>> API's
>> which are being called? I am trying to debug a exception that causes an
>> application
>> to crash. As usual I do
On Wed, Jul 2, 2008 at 10:29 PM, Chris Ahrendt <[EMAIL PROTECTED]> wrote:
> Is there a way within wine or wine debug to tell it to output just the
> API's
> which are being called? I am trying to debug a exception that causes an
> application
> to crash. As usual I don't have the windows source c
On Wed, Jul 2, 2008 at 10:29 PM, Chris Ahrendt <[EMAIL PROTECTED]> wrote:
> Is there a way within wine or wine debug to tell it to output just the
> API's
> which are being called? I am trying to debug a exception that causes an
> application
> to crash. As usual I don't have the windows source c
On 6/18/07, Damjan Jovanovic <[EMAIL PROTECTED]> wrote:
only appear in +snoop, not in +relay. And is there a way for a builtin
DLL to LoadLibrary() the native DLL of the same name and call
functions in it? It would be very useful in narrowing down the bug.
You can definitely use LoadLibrary()
On 3/19/07, Stephan Rose <[EMAIL PROTECTED]> wrote:
On Mon, 2007-03-19 at 09:40 +0100, Stefan Dösinger wrote:
> Am Montag 19 März 2007 01:49 schrieb Stephan Rose:
> > I've been playing around with the supreme commander install most of
> > today trying to figure out why it does not want to install
On Mon, 2007-03-19 at 09:40 +0100, Stefan Dösinger wrote:
> Am Montag 19 März 2007 01:49 schrieb Stephan Rose:
> > I've been playing around with the supreme commander install most of
> > today trying to figure out why it does not want to install. Running with
> > +file,+msgbox and noticed the follo
Stephan Rose wrote:
I've been playing around with the supreme commander install most of
today trying to figure out why it does not want to install. Running with
+file,+msgbox and noticed the following error for virtually all files:
warn:file:wine_nt_to_unix_file_name L"TUB500.xsb" not found
in /
Am Montag 19 März 2007 01:49 schrieb Stephan Rose:
> I've been playing around with the supreme commander install most of
> today trying to figure out why it does not want to install. Running with
> +file,+msgbox and noticed the following error for virtually all files:
> So it seems that it freaks
After doing the suggested tactis it still failed but with fewer errors:
Here is the output
"
fixme:msvcrt:MSVCRT__wsetlocale 4 L"English_United States.1252"
fixme:msvcrt:MSVCRT__wsetlocale 4 L"C"
fixme:msvcrt:MSVCRT__wsetlocale 4 L"English_United States.1252"
fixme:msvcrt:MSVCRT__wsetlocale 4 L"
On 11/15/06, Kartik Thakore <[EMAIL PROTECTED]> wrote:
After doing the suggested tactis it still failed but with fewer errors:
Did you already setup a bug number for this? what number? It would be
best to attach log outputs to the bug report.
Doesn't Solidworks use the (Macromedia) Safecast co
After doing the suggested tactis it still failed but with fewer errors:
Here is the output
"
fixme:msvcrt:MSVCRT__wsetlocale 4 L"English_United States.1252"
fixme:msvcrt:MSVCRT__wsetlocale 4 L"C"
fixme:msvcrt:MSVCRT__wsetlocale 4 L"English_United States.1252"
fixme:msvcrt:MSVCRT__wsetlocale 4 L"
First thing to do is to open bug at bugs.winehq.org and describe your
problem there.
Then, please try to:
1) copy msimtf.dll from Windows to your wine's system32, register it
with regsvr32 and try if Solid Works issue persists
2) copy atl.dll from Windows to your wine's system32, register it and
On 7/6/06, Dmitry Timoshkov <[EMAIL PROTECTED]> wrote:
> http://bugs.winehq.org/show_bug.cgi?id=4063 is a crash
> on exit from a VB6 app due to a _CheckNotSysLevel() error.
> What typically causes these - are they a bug in the windows
> program? And is there a good reference from understanding
>
On Fri, 07 Jul 2006 00:24:49 -0700, Dan Kegel wrote:
> http://bugs.winehq.org/show_bug.cgi?id=4063 is a crash
> on exit from a VB6 app due to a _CheckNotSysLevel() error.
> What typically causes these - are they a bug in the windows
> program? And is there a good reference from understanding
> the
"Dan Kegel" <[EMAIL PROTECTED]> wrote:
http://bugs.winehq.org/show_bug.cgi?id=4063 is a crash
on exit from a VB6 app due to a _CheckNotSysLevel() error.
What typically causes these - are they a bug in the windows
program? And is there a good reference from understanding
the whole syslevel thing
> I think the bug is here. Using SysAllocString instead of
> SysAllocStringLen I get:
>
> VarBstrCmp returns 1
> CompareStringW returns 2
Using SysAllocString, I get that the length of each string is 0.
So yeah, they'd be equal.
So, I'm back to where I started: in Windows, these are different
c
Juan Lang wrote:
You missed the two collation_table lookups.
You're right, I did miss that.
Note that on Windows using CompareString on L"\0001\0002" and
L"\0002\0001" gives a result of CSTR_EQUAL, so I don't think the bug is
in the collation tables.
Really? For which locale
> You missed the two collation_table lookups.
You're right, I did miss that.
> Note that on Windows using CompareString on L"\0001\0002" and
> L"\0002\0001" gives a result of CSTR_EQUAL, so I don't think the bug is
> in the collation tables.
Really? For which locale, and which version of Wind
Juan Lang wrote:
I'm trying to figure out why CompareStringA returns CSTR_EQUAL for the strings "\1" and
"\2". (See bug 5469, and the todo_wine test case in dlls/kernel/tests/locale.c)
CompareStringA does the usual thing, calls MultiByteToWideChar and calls CompareStringW. So
CompareStringW
- Original Message -
From: "Juan Lang" <[EMAIL PROTECTED]>
To:
Sent: Wednesday, June 28, 2006 12:20 AM
Subject: Debugging string comparison problem
I'm trying to figure out why CompareStringA returns CSTR_EQUAL for the strings "\1" and "\2". (See bug 5469, and the
todo_wine test case
On Tue, 28 Mar 2006 15:25:26 -0500
Segin <[EMAIL PROTECTED]> wrote:
>(Try this: select some text in Wine, and middle click in a
> Xterm, nothing happens! Go back to the Windows app, tell it to copy the
> text, and try to paste it into the xterm, nothing again! I think it's a
> bug IMHO)
You nee
Andreas Mohr wrote:
Hi,
On Tue, Mar 28, 2006 at 03:39:43AM -0800, Dan Kegel wrote:
OK, I've had it. The X errors I'm running into are keeping
me from getting work done. They might be due to
bugs in my X server (ubuntu 05.10), but while I wait
for the next release of ubuntu, mayb
Andreas Mohr wrote:
Hi,
On Tue, Mar 28, 2006 at 03:39:43AM -0800, Dan Kegel wrote:
OK, I've had it. The X errors I'm running into are keeping
me from getting work done. They might be due to
bugs in my X server (ubuntu 05.10), but while I wait
for the next release of ubuntu, mayb
Hi,
On Tue, Mar 28, 2006 at 03:39:43AM -0800, Dan Kegel wrote:
> OK, I've had it. The X errors I'm running into are keeping
> me from getting work done. They might be due to
> bugs in my X server (ubuntu 05.10), but while I wait
> for the next release of ubuntu, maybe I could try
> to track them
On Friday 24 February 2006 13:46, Stefan Dösinger wrote:
> Hi,
>
> > As such, I'm looking for a little advice on debugging issues when apps
> > don't work (yes, I've read what's on winehq.) I have the application
> > KeePass (keepass.sourceforge.net) which installs just fine. When I go to
> > run
Hi,
> As such, I'm looking for a little advice on debugging issues when apps
> don't work (yes, I've read what's on winehq.) I have the application
> KeePass (keepass.sourceforge.net) which installs just fine. When I go to
> run it, it just drops me right back to the prompt.
Pardon my ignorance,
Hi,
On Friday 24 February 2006 06:28, Juan Lang wrote:
> As far as how to deal with this, try modifying kernel32.spec to add a stub
> for BlockInput, like:
> @ stub BlockInput
> and see if the program gets any further.
Hi according to MSDN, BlockInput is a user32.dll function:
http://msdn.micro
> I appreciate the tip about falling back on the relay debug channel,
> but may I ask how you know the problem is with BlockInput not existing?
> Is there something from the output that I'm not understanding, or do
> you just know that because you're familiar with the kernel32.dll
> code?
Molle's
Rich Gilson wrote:
> I appreciate the tip about falling back on the relay debug channel, but may I
> ask how you know the problem is with BlockInput not existing? Is there
> something from the output that I'm not understanding, or do you just know
> that because you're familiar with the kernel32.d
I appreciate the tip about falling back on the relay debug channel, but may I
ask how you know the problem is with BlockInput not existing? Is there
something from the output that I'm not understanding, or do you just know
that because you're familiar with the kernel32.dll code?
I'm a long way
Hi Rich, the key one to use is relay. WINEDEBUG=relay tells you every API
function that's called. It can be a bit overwhelming, but it's what you
fall back on when nothing else is working.
I downloaded and tried it, and scanned backwards in my relay trace a good
distance till I saw some failure.
Marcus Meissner wrote:
On Sat, Jan 14, 2006 at 08:41:50PM +0100, Christer Palm wrote:
After messing around with with the mfc42 runtime, I managed to get a
backtrace with debugging information, which looks like this:
=>1 0x5f4056dd CEnumOleVerb::~CEnumOleVerb+0x37 [oleverb.cpp:61] in
mfc42
On Sat, Jan 14, 2006 at 08:41:50PM +0100, Christer Palm wrote:
> Hi!
> I'm new to this list, but a long time Wine user and regular WWN reader.
>
> The other day I decided to try out Semiolog, a free as-in-beer piece of
> software to create labels from electric equipment manufacturer Hager,
> und
Robert Reif wrote:
I'm trying to help someone on wine-bugs
(http://bugs.winehq.org/show_bug.cgi?id=4053) with a crash in a game.
The problem is that the game is catching and displaying the exception.
It also appears that the game won't run in winedbg.
Does anyone have any ideas on how to pr
On Sat, 2005-12-24 at 10:04 -0500, Robert Reif wrote:
> I'm trying to help someone on wine-bugs
> (http://bugs.winehq.org/show_bug.cgi?id=4053) with a crash in a game.
>
> The problem is that the game is catching and displaying the exception.
> It also appears that the game won't run in winedbg
Michael Ost wrote:
Does anyone know how to set up Eclipse to debug winelib applications?
I tried just replacing 'gdb' with 'winedbg' on the "Debugger" tab on the
"Debug" window. After Eclipse says "Launching..." there is an error that
says "Process terminated."
After reviewing the winelib de
Michael Ost wrote:
Does anyone know how to set up Eclipse to debug winelib applications?
I tried just replacing 'gdb' with 'winedbg' on the "Debugger" tab on the
"Debug" window. After Eclipse says "Launching..." there is an error that
says "Process terminated."
After reviewing the winelib de
On 12/2/05, Michael Ost <[EMAIL PROTECTED]> wrote:
> Does anyone know how to set up Eclipse to debug winelib applications?
>
> I tried just replacing 'gdb' with 'winedbg' on the "Debugger" tab on the
> "Debug" window. After Eclipse says "Launching..." there is an error that
> says "Process terminat
Robert Shearman wrote:
Yep, example of what not to do in concurrent programming. You should
Tell me about it - I do hard realtime for a living.
One of the locks is the Win6 lock, another does not seem to have a name
(shown as "?" when things go bad). I wonder if, under Real Windows, the
Win
David D. Hagood wrote:
Robert Shearman wrote:
David D. Hagood wrote:
Unless the installer is using TryEnterCriticalSection, I would expect
CPU utilisation to be 0% when deadlocking.
Yes, *once the deadlock occurs* the CPU drops to 0%. The issue (I
think) is more along the lines of t
Robert Shearman wrote:
David D. Hagood wrote:
Unless the installer is using TryEnterCriticalSection, I would expect
CPU utilisation to be 0% when deadlocking.
Yes, *once the deadlock occurs* the CPU drops to 0%. The issue (I think)
is more along the lines of this:
On fast CPU:
thread
David D. Hagood wrote:
I may have a repeatable case of an error in locking critical sections,
so I'd like some pointers as to how to debug this.
The case occurs with the installer for Delorme Street Atlas 5 - on my
2GHz Athlon desktop it runs without a hitch, but on my oold slow
laptop (
On Sun, 09 Oct 2005 10:42:13 +0200, wino wrote:
> I am trying to debug an app and making good progress with on sorting out
> the dlls reqd. but now have an exception I dont know how to follow.
Look at the debugging guides we wrote on the wiki. For this kind of bug, a
+relay,+tid,+seh trace is a go
David Hemmo a écrit :
what's strange is that esp is within stack limit... wine exception
handler must this from another part... it may come from msvcmon
tweaking the selectors (cs, ss) for some reasons
I agree it is strange but it still comes up after a bunch of "001b:
*signal* signal=5" t
what's strange is that esp is within stack limit... wine exception
handler must this from another part... it may come from msvcmon
tweaking the selectors (cs, ss) for some reasons
I agree it is strange but it still comes up after a bunch of "001b:
*signal* signal=5" that should not be there
David Hemmo a écrit :
Eric Pouech wrote:
- kernel send a trap signal
- wine's ntdll catches it, and queue the information as a debug event
in the wineserver
- the debugger (msvcmon in your case) get notified of the trap while
waiting for a debug event
I understand.
I made a log of what happens w
Eric Pouech wrote:
- kernel send a trap signal
- wine's ntdll catches it, and queue the information as a debug event in
the wineserver
- the debugger (msvcmon in your case) get notified of the trap while
waiting for a debug event
I understand.
I made a log of what happens when I single step with
David Hemmo a écrit :
Hello,
After reading a mail exchanges about ptrace on Linux, I decided to
switch to a newer Linux kernel to see how it modified my problem.
Things got worse. Restarting a program from Visual studio stopped working.
Is there anyone that can explain me how things are supposed
On Sun, Apr 24, 2005 at 09:23:22AM +1000, Troy Rollo wrote:
> On Saturday 23 April 2005 22:12, Alex Woods wrote:
> > I'm attaching to the process with gdb, but it's not catching things at
> > the point where they go wrong. Typically I am just seeing a stack like
> > this though:
> > #0 0x56752a01
On Saturday 23 April 2005 22:12, Alex Woods wrote:
> I'm attaching to the process with gdb, but it's not catching things at
> the point where they go wrong. Typically I am just seeing a stack like
> this though:
> #0 0x56752a01 in ?? ()
If it's only giving one frame in the stack trace the cause
> In that case, what is "winedbg --gdb" for? Why have this option if no
GDB supports it?
because it targets different stuff:
winedbg (standalone) is able to load and use debug info from:
- ELF modules (exec and shared libs) (with stabs info, dwarf2 isn't supported).
As wine DLLs are implemented o
Eric Pouech wrote:
Could you give any hints as to how to configure GDB with 'stabs in
PE' support? The only reference I could find in the GDB documentation
is:
"6.4.5 PE
Windows 95 and NT use the PE (/Portable Executable/) format for their
executables. PE is basically COFF with additional heade
Bryce McKinlay a écrit :
Eric Pouech wrote:
Bryce McKinlay a écrit :
I'm trying to debug a windows .exe built with mingw using wine, but
winedbg seems to have problems reading stabs from the mingw-built
binary. My goal is to be able to debug a cross-compiled, native Java
(GCJ) application, but e
Eric Pouech wrote:
Bryce McKinlay a écrit :
I'm trying to debug a windows .exe built with mingw using wine, but
winedbg seems to have problems reading stabs from the mingw-built
binary. My goal is to be able to debug a cross-compiled, native Java
(GCJ) application, but even a simple C "hello wor
Dimitrie O. Paun a écrit :
On Sun, Jan 02, 2005 at 11:35:07AM +0100, Eric Pouech wrote:
winedbg using the gdb won't work here because (likely on unix) gdb isn't
compiled with proper 'stabs in PE' support
Maybe we should lobby people (like Fedora) to enable it by default.
but this would require
1 - 100 of 125 matches
Mail list logo
