Almost all bugs that come from Ubuntu users don't have usable backtraces. Instead they have this:
Process of pid=0008 has terminated No process loaded, cannot execute 'echo Modules:' Cannot get info on module while no process is loaded
Needless to say this doesn't help with troubleshooting the problem. Does anyone have a clue what might be the problem?
Vitaliy.
Needless to say this doesn't help with troubleshooting the problem. Does anyone have a clue what might be the problem?
I looked up the maintainer of the package.. Ubuntu MOTU Developers ubuntu-motu@lists.ubuntu.com
You could try asking there?
Perhaps debug info is compiled out or so. For example I just saw this bug: http://bugs.winehq.org/show_bug.cgi?id=15368
The game crashes somewhere in ddraw/wined3d but it only shows crap like: Backtrace: =>1 0x7eb1b014 in ddraw (+0xb014) (0x0032f6d4) 2 0x7e5b6c7f in wined3d (+0x36c7f) (0x0032f834) 3 0x7eb20a1c in ddraw (+0x10a1c) (0x0032f884) 4 0x7e5b8f38 in wined3d (+0x38f38) (0x0032f8c4) 5 0x7eb1f3c8 in ddraw (+0xf3c8) (0x0032fa64)
I would expect to see function names.
Roderick
Almost all bugs that come from Ubuntu users don't have usable backtraces. Instead they have this:
Process of pid=0008 has terminated No process loaded, cannot execute 'echo Modules:' Cannot get info on module while no process is loaded
Needless to say this doesn't help with troubleshooting the problem. Does anyone have a clue what might be the problem?
Vitaliy.
On Sun, Sep 21, 2008 at 04:38:15PM -0600, Vitaliy Margolen wrote:
Almost all bugs that come from Ubuntu users don't have usable backtraces. Instead they have this:
Process of pid=0008 has terminated No process loaded, cannot execute 'echo Modules:' Cannot get info on module while no process is loaded
Needless to say this doesn't help with troubleshooting the problem. Does anyone have a clue what might be the problem?
Vitaliy.
Believe that building deb packages will strip debuging symbols from the binaries but unlike rpm does not by default create a debuginfo like package and place the corresponding symbols in there.
Darragh Bailey wrote:
On Sun, Sep 21, 2008 at 04:38:15PM -0600, Vitaliy Margolen wrote:
Almost all bugs that come from Ubuntu users don't have usable backtraces. Instead they have this:
Process of pid=0008 has terminated No process loaded, cannot execute 'echo Modules:' Cannot get info on module while no process is loaded
Needless to say this doesn't help with troubleshooting the problem. Does anyone have a clue what might be the problem?
Vitaliy.
Believe that building deb packages will strip debuging symbols from the binaries but unlike rpm does not by default create a debuginfo like package and place the corresponding symbols in there.
I'm not talking about debug symbols - those are stripped in all binary packages. The issue is winedbg can't even start & attach to the process properly. It's either a race of sorts, or something preventing it from starting properly.
Vitaliy
On Mon, Sep 22, 2008 at 07:23:57AM -0600, Vitaliy Margolen wrote:
Darragh Bailey wrote:
On Sun, Sep 21, 2008 at 04:38:15PM -0600, Vitaliy Margolen wrote: Believe that building deb packages will strip debuging symbols from the binaries but unlike rpm does not by default create a debuginfo like package and place the corresponding symbols in there.
I'm not talking about debug symbols - those are stripped in all binary packages. The issue is winedbg can't even start & attach to the process properly. It's either a race of sorts, or something preventing it from starting properly.
Vitaliy
Sorry, meant to direct the response at the email in the thread mentioning that they had a backtrace without any function names present.
On Monday 22 September 2008 06:23:57 am Vitaliy Margolen wrote:
I'm not talking about debug symbols - those are stripped in all binary packages. The issue is winedbg can't even start & attach to the process properly. It's either a race of sorts, or something preventing it from starting properly.
FWIW, I sometimes see this happen even when compiled from GIT. It doesn't always happen though (more often than not it doesn't). It could be some sort of race condition in Wine that certain apps may be more prone to causing.
When I turned on the debugging flag +ntdll I noticed a rather strange behavior in wine. But before I open a bug on it I wanted to understand how the shared libraries that emulate the various windows dll's are handled. When I turned on the +ntdll flag I started getting several file not found errors in the logs as it searched for the dll's... One such example is advapi32.dll. This is handled by the shared library file of the same name. Shouldn't the dll loader recognize this as a SO and return the fact it found it???
I also noticed another bit of weirdness as well... If the application loads the "COMCTL32.dll" file or the "Comctl32.dll" it wont find it but if it loads comctl32.dll it does. Now I know this is partially the way the file system handles the files, but shouldn't it find the file if it exists even with the capitalization screwy? It doesn't seem to happen that often the ones I have noticed the error occurring are : Comctl32 COMCTL32 msvcrt MSVCRT msvfw32 MSVFW32 WS2_32 ws2_32
I am just wondering if because of the above some of the weirder errors we are seeing might be caused by this? Or at the least are filling up trace logs when they don't need too...
Chris
Chris Ahrendt wrote:
When I turned on the debugging flag +ntdll I noticed a rather strange behavior in wine. But before I open a bug on it I wanted to understand how the shared libraries that emulate the various windows dll's are handled. When I turned on the +ntdll flag I started getting several file not found errors in the logs as it searched for the dll's... One such example is advapi32.dll. This is handled by the shared library file of the same name. Shouldn't the dll loader recognize this as a SO and return the fact it found it???
Everything is perfectly normal. Wine has number of places where it looks for builtin then native files (if builtin wasn't found). Of course usable file will exist in only one place.
Vitaliy
Vitaliy Margolen wrote:
Chris Ahrendt wrote:
When I turned on the debugging flag +ntdll I noticed a rather strange behavior in wine. But before I open a bug on it I wanted to understand how the shared libraries that emulate the various windows dll's are handled. When I turned on the +ntdll flag I started getting several file not found errors in the logs as it searched for the dll's... One such example is advapi32.dll. This is handled by the shared library file of the same name. Shouldn't the dll loader recognize this as a SO and return the fact it found it???
Everything is perfectly normal. Wine has number of places where it looks for builtin then native files (if builtin wasn't found). Of course usable file will exist in only one place.
Vitaliy
What about this part of the question as well...
This occurs on non built in DLL's :
I also noticed another bit of weirdness as well... If the application loads the "COMCTL32.dll" file or the "Comctl32.dll" it wont find it but if it loads comctl32.dll it does. Now I know this is partially the way the file system handles the files, but shouldn't it find the file if it exists even with the capitalization screwy? It doesn't seem to happen that often the ones I have noticed the error occurring are : Comctl32 COMCTL32 msvcrt MSVCRT msvfw32 MSVFW32 WS2_32 ws2_32
I am just wondering if because of the above some of the weirder errors we are seeing might be caused by this? Or at the least are filling up trace logs when they don't need too...
Chris
Chris Ahrendt wrote:
I also noticed another bit of weirdness as well... If the application
You missing the part that those dlls where loaded successfully. You keep looking for problems in the wrong places.
Vitaliy
Vitaliy Margolen wrote:
Chris Ahrendt wrote:
I also noticed another bit of weirdness as well... If the application
You missing the part that those dlls where loaded successfully. You keep looking for problems in the wrong places.
Vitaliy
That is incorrect.. they didnt load is the point I am making... And this was a curious behaviour not part of me looking for any problems
Chris
Chris Ahrendt wrote:
Vitaliy Margolen wrote:
Chris Ahrendt wrote:
I also noticed another bit of weirdness as well... If the application
You missing the part that those dlls where loaded successfully. You keep looking for problems in the wrong places.
That is incorrect.. they didnt load is the point I am making... And this was a curious behaviour not part of me looking for any problems
If they wouldn't load you would have seen totally different results and error message.
Vitaliy
-
Andrew Fenn -
Chris Ahrendt -
Chris Robinson -
Darragh Bailey -
Roderick Colenbrander -
Vitaliy Margolen