Regular crashes are back with 1.73.4 :(

Post by **another_commander** » Tue Sep 29, 2009 8:05 pm

drew: Does it also crash without any OXPs?

drew · Post by **drew** » Tue Sep 29, 2009 8:11 pm

Yes. Tried plain vanilla versions with no OXPs and the longest I've managed before a crash is about 15-20 minutes on both 1.73.3 and 1.73.4.

Cheers,

Drew.

Screet · Post by **Screet** » Wed Sep 30, 2009 9:01 am

Hmmm.

Wish I had my nice development environment...gdb even does write error messages and warnings on top of each other, making it pretty unreadable

I just did make a debug run and let the pilot fly cloaked without any further interaction. Before the energy was drained from the cloak, the game crashed as expected.

Inmidst the "assigning non-constant to 'const float'" there's this on the output (with the missing character!):

Code: Select all

warning: ERROR:
warnin
Program received signal SIGSEGV, Segmentation fault.
0x63d0d80a in _libws2_32_a_iname ()
(gdb) g: compilation errors. No code generated.

warning: ERROR:
warning 1:12
warning: :
warning: '=' assigning non-constant to 'const float'

warning: ERROR:
warning:  compilation errors. No code generated.

warning: WARNING:
warning: built-in varying gl_TexCoord [0] has mismatched access semantics between the vertex and fragment shader

I can't see much from this.

Screet

Post by **another_commander** » Wed Sep 30, 2009 10:40 am

The assigning float to const float etc. messages, together with the gl_TexCoord[0] one are errors in shaders (can't tell you which ones with the information shown here). The crash message itself does not reveal anything, because the crash happens outside of the executable, in one of the support libraries. Usually this means that the support library has received bogus data from the executable. To be able to see something useful, next time it crashes type bt (backtrace) in the gdb command line and post the stack frame dump here.

Screet · Post by **Screet** » Wed Sep 30, 2009 11:20 am

another_commander wrote:
To be able to see something useful, next time it crashes type bt (backtrace) in the gdb command line and post the stack frame dump here.

It's ALL in that lib.

Several times _libws2_32_a_iname () is listed, the other times just ?? ()

Is there a way to expand the backtrace beyond 24 lines?

Screet

Post by **another_commander** » Wed Sep 30, 2009 11:24 am

The backtrace by default is shown from crash point to start up at main. What is the size in KB of the exe you are using? Are you doing this on Vista64 or 32 bit?

Screet · Post by **Screet** » Wed Sep 30, 2009 11:55 am

another_commander wrote:
The backtrace by default is shown from crash point to start up at main. What is the size in KB of the exe you are using? Are you doing this on Vista64 or 32 bit?

Oolite is at 657K, task manager reports that in total half of the machines 2 GiB are being used by all programs together.

Both #0 and #23 in bt are reporting _libws2_32_a_iname ()

I have to use that old XP machine with 32bit OS as these tools do not like Vista64.

Screet

Post by **another_commander** » Wed Sep 30, 2009 12:13 pm

Are you sure it's 657K and not 6570K or similar? If it is indeed 657K, then you are using a (very) stripped executable, which does not contain debug info and is expected to not show anything under gdb. For reference, on my system, a stripped exe is around 2300K, non-stripped 9598K.

Screet · Post by **Screet** » Wed Sep 30, 2009 12:28 pm

another_commander wrote:
Are you sure it's 657K and not 6570K or similar? If it is indeed 657K, then you are using a (very) stripped executable, which does not contain debug info and is expected to not show anything under gdb. For reference, on my system, a stripped exe is around 2300K, non-stripped 9598K.

Me being almost asleep..M not K. Slightly over half a gigabyte of RAM being used.

If you talk about the executable, I've shut down the machine, but IIRC it was slightly below 10 megabytes.

Screet

Screet · Post by **Screet** » Wed Sep 30, 2009 9:38 pm

Hi,

since that debugging attempt didn't help much and I don't know how much that library is used...would it be a problem to add additional checks before making calls to that library in order to find the source of that problem?

Screet

Post by **another_commander** » Wed Sep 30, 2009 9:54 pm

That library is called internally. There is no way we can add checks to trap what is happening with it when called. Plus, we would not be able to do anything about it even if we were able to add checks. Since your executable behaves exactly like a stripped one, the best thing that can be done is to change strategy, i.e. forget debugging it, remove all oxps and try to find a way to reproduce the crash reliably instead.

Screet · Post by **Screet** » Wed Sep 30, 2009 10:32 pm

another_commander wrote:
That library is called internally. There is no way we can add checks to trap what is happening with it when called. Plus, we would not be able to do anything about it even if we were able to add checks. Since your executable behaves exactly like a stripped one, the best thing that can be done is to change strategy, i.e. forget debugging it, remove all oxps and try to find a way to reproduce the crash reliably instead.

There is a reliable way to reproduce the crash: Launch, witchspace and then leave the computer alone. Cloak the ship to increase survival chances...the crash typically happens much faster than the cloak can drain the energy.

The crash does not require any user interaction. It's simply happening after a brief amount of time, typically way before the ship could reach the planet.

EDIT: Maybe it requires the ship to be in a star system. The reason is that I do not remember any crashes while being in interstallar space for a long time (thargoid hive from cataclysm). Might have been luck, though. However, the game crashed several times before I could dock after I jumped to a system when the mission was finished. The crash also occurs without that oxp...and as someone wrote already, without any oxps.

Screet

zevans · Post by **zevans** » Thu Oct 01, 2009 12:15 am

If it doesn't happen in Witchspace... dare I ask... could it be return of the dreaded textured planet weirdness?

Screet - what graphics chipset you on? I had a situation on mine where my graphics stack was falling over with oolite and wasn't falling over with a couple of other 3d games, so I think oolite might be quite good at knocking over otherwise happy graphics stacks! ( I was using an alpha-quality release of the graphics drivers, but the point is oolite and only oolite managed to knock them over.)

Post by **another_commander** » Thu Oct 01, 2009 5:58 am

Screet wrote:
There is a reliable way to reproduce the crash: Launch, witchspace and then leave the computer alone. Cloak the ship to increase survival chances...the crash typically happens much faster than the cloak can drain the energy.

I cannot reproduce any crash the way you describe. That is after leaving the game running for more than about twenty minutes and jumping through two or three systems, both with trunk and 1.73.4.

Screet · Post by **Screet** » Thu Oct 01, 2009 6:57 am

zevans wrote:
Screet - what graphics chipset you on? I had a situation on mine where my graphics stack was falling over with oolite

1) nVidia GTX 295 with a Vista 64 system
2) ATI X800XTPE with a XP 32 system

Screet