Crash with 'Tried to access invalid particle channel (invalid ID)'

[attila123]

Hi,

I was playing with a version I built and installed from dev not so long time ago.
Currently on Linux Mint 18.
It crashed with:
`INFO: Colobot: Gold Edition 0.1.8+alpha-git-dev~raa6345a starting
INFO: Creating CApplication
INFO: Data path: /opt/colobot/share/games/colobot
INFO: Save path: /home/avangel/.local/share/colobot
INFO: Opening audio device...

INFO: CApplication created successfully
INFO: Error on parsing config file: No such node (Experimental.OpenGLVersion)
INFO: Error on parsing config file: No such node (Experimental.OpenGLProfile)
INFO: Error on parsing config file: No such node (Experimental.MSAA)
INFO: Error on parsing config file: No such node (Experimental.VSync)
INFO: No joysticks detected
INFO: Error on parsing config file: No such node (Experimental.GraphicsDevice)
INFO: Creating CDevice - OpenGL 1.4
INFO: OpenGL 3.0 Mesa 11.2.0
INFO: Mesa DRI Intel(R) Haswell Mobile
INFO: Shadow mapping available (core)
INFO: Anisotropic filtering available
INFO: Maximum anisotropy: 16
INFO: Multisampling supported, max samples: 8
INFO: Auto-detecting VBO support
INFO: Core VBO supported
INFO: Maximum texture units: 8
INFO: Maximum texture size: 8192
INFO: Framebuffer supported (ARB)
INFO: Maximum renderbuffer size: 8192
INFO: CDevice created successfully
INFO: Closing joystick
INFO: Created shadow map texture: 2048x2048, depth 32
INFO: Reseting world on phase change...
INFO: Simulation speed = 1.00
INFO: Loading level: levels/missions/chapter006/level002/scene.txt
[WARN]: This level is using deprecated way of defining win scene. Please remove the win= parameter in EndingFile.
[WARN]: This level is using deprecated way of defining lost scene. Please change the lost= parameter in EndingFile from 0 to "levels/other/lost000.txt".
INFO: Start suspend
[WARN]: Creating non-power-of-2 texture (400x225)!
INFO: Stop suspend
INFO: Start suspend
[WARN]: Creating non-power-of-2 texture (400x225)!
INFO: Stop suspend
INFO: Reseting world on phase change...
INFO: Simulation speed = 1.00
INFO: Loading level: levels/missions/chapter006/level002/scene.txt
[WARN]: This level is using deprecated way of defining win scene. Please remove the win= parameter in EndingFile.
[WARN]: This level is using deprecated way of defining lost scene. Please change the lost= parameter in EndingFile from 0 to "levels/other/lost000.txt".

Unhandled exception occurred!

Type: std::runtime_error

Message: Tried to access invalid particle channel (invalid ID)

This is usually caused by a bug. Please report this on http://github.com/colobot/colobot/issues

including information on what you were doing before this happened and all the information below.

You seem to be running a custom compilation of version git-dev~raa6345a, but please verify that.

The game was in phase PHASE_SIMUL (ID=7)

Last started level was: category=missions chap=6 rank=2

Sorry for inconvenience!
Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.
Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.
Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.
AL lib: (EE) alc_cleanup: 1 device not closed
`

[attila123]

crashsave.zip

[attila123]

After

git pull
cd build
make clean
make
sudo make install

I lost my progress. :( So I cannot see the completed missions. But of course I can use the saved games.
Anyway the problem is still present in the latest 0.1.8+alpha-git-dev~r210b5c2.
Especially flying to the middle island and killing a lot of ants seem to trigger the crash.
Only way to make it stable seems to be to set the graphics settings to Lowest!
I used 1600x900 full screen if that matters.

[attila123]

A bit off, I tried to download the 0.1.7b version and run it:
./colobot: error while loading shared libraries: libGLEW.so.1.10: cannot open shared object file: No such file or directory
I have libGLEW 1.13 installed (Linux Mint 18, which is built on Ubuntu 16.04(.1?)).
I am not familiar how to make this less fragile. Maybe statically linking could help?
Update: rebooted to Linux Mint 17.3. After installing the libsdl2 libraries, the libboost dependency seems not to be satisfiable here:
./colobot: error while loading shared libraries: libboost_system.so.1.58.0: cannot open shared object file: No such file or directory
The problem is that the libboost libraries here are 1.55 and 1.54 (checked in the synaptic package manager).
So the Linux pre-compiled binary seems to be quite unusable on most systems.

[VictorDenisov]

I encountered the same problem when I was shooting alien ant and also shot uranium ore. During the destruction of uranium ore this error message appeared: Tried to access invalid particle channel. I used commit 407d855

[VictorDenisov]

I repeated shooting alien ant and uranium ore and couldn't reproduce the issue. So, the reproduction is unstable.

[VictorDenisov]

Attacking one object at a time doesn't seem to produce this effect. It looks like it happens only when I attack two objects that are very close to each other.

[attila123]

Max out all the graphics settings, then try the following crashsave to reproduce the crash. For me it always reproduces.
crashsave.zip
(extract to the colobot directory where the saved games are, e.g. ~/.local/share/colobot/ on Linux).
I consider this a critical bug.

[tomangelo2]

I can confirm that it happen on this save.

[paulmotey]

I have forked and I have a local copy to experiment with and I have been debugging this issue for some time. I discovered a few errors and some are fixed in the dev branch. I have a good idea of why this happens and it is very reproducible for me to trace in GDB or DDD as well as Eclipse. There are issues with particles and how that is integrated. As yet I do not have a complete grasp of the code base and there are places that I see could have major improvements like object "GOTO" could be way faster and more reliable. I am studying the how to dev documents and will see if I can't come up with a fix that isn't too complex that deals with the particle array assignment to specific objects.
This is a bit sideways, but has anybody considered giving each object in the game a UID ( Unique ID)?

[krzys-h]

@paulmotey They already have unique IDs, see https://github.com/colobot/colobot/blob/dev/src/object/object.h#L216
If you are willing to improve goto() algorithm that would be greatly appreciated, it's been on our TODO list for ages.

I'm pretty sure the main problem in this issue is that I was messing with the particle implementation in 99a831a (and d80fa38) and I added this exception as a way to find all locations in the code that generated warnings in the logs. Some code is likely trying to call some function in CParticle with -1 or something, it should be rather easy to fix once I'll actually have some time to try to reproduce this issue.

[paulmotey]

I added
m_partiSphere = -1;
on line 318 of autopowerplant.cpp in the dev branch
and it solved the crash problem
I created a program for code battles vs computer that crashes every time with dev and does not crash when using the debian version.
It is my opinion that if you wish to clean up particles from a destroyed object that it would require that that variable be set and cleared in every stage of an object's particle operation.
More recently I have been hunting a bug that writes memory at random and I suspect an array that gets accessed out of its bounds.
The fix needs to be in place in autolabo.cpp as well if it is done that way.
I am still getting familiar with the code and hope to contribute a goto that works properly and can be enabled and disabled with a flag.
I am creating a "code battle" enemy and friendly program set that is a diagnostic that will test all kinds of rzecvy.

[paulmotey]

Hunting bug write memory at random was a wild goose chase. I accidentally triggered some incomplete functions that deal with teams and spent a great deal of time finding out it was not a memory problem at all. I did learn almost everything about the structure of the code and now have a decent understanding of its operation.

[krzys-h]

This should be fixed now, sorry for the trouble