- Status Closed
- Percent Complete
- Task Type Bug Report
- Category
- Assigned To No-one
- Operating System
- Severity Low
- Priority
- Reported Version
- Due in Version Undecided
-
Due Date
Undecided
- Votes
- Private
Opened by Steven Schwartfeger - 29.10.2007
Last edited by Steven Schwartfeger - 28.07.2009
FS#547 - Client crash when ps window not in focus
I have had this crash 5 times now, all after something happened in a client that was not in focus (dual clients for testing).
I tried to figure this out, here is the first part of bt full:
(gdb) bt full
#0 0x0000000000425f2a in psCamera::FindMeshUnder2D (this=0x1130290, x=<value optimized out>, y=758, pos=0x0, poly=<value optimized out>)
at src/client/pscamera.cpp:918
end = {{{x = -240.538208, y = -83.4431381, z = 21.3170319}, m = {-240.538208, -83.4431381, 21.3170319}}}
result = {mesh = 0x3d019e33dc, isect = {{{x = 5.81142239e-38, y = 1.55852415e-41, z = -3.30167209e-14}, m = {5.81142239e-38,
1.55852415e-41, -3.30167209e-14}}}, polygon_idx = 32767, final_sector = 0x4965e4}
vc = {{{x = 0.0872395858, y = -0.486979187, z = 1}, m = {0.0872395858, -0.486979187, 1}}}
vo = {{{x = -231.814758, y = 27.0156193, z = 34.3694}, m = {-231.814758, 27.0156193, 34.3694}}}
vw = {{{x = -231.901993, y = 25.9110317, z = 34.2388763}, m = {-231.901993, 25.9110317, 34.2388763}}}
perspective = {x = 579, y = 10}
sector = (class iSector *) 0x2aaac0955ff4
the only suspicious looking part there I could see is "polygon_idx = 32767", but I cannot find the implementation of HitBeamPortals in either cs or ps to see what it does.
Core was generated by `./psclient'.
Program terminated with signal 11, Segmentation fault.
#0 0x0000000000425f2a in psCamera::FindMeshUnder2D (this=0x1130290, x=<value optimized out>, y=758, pos=0x0, poly=<value optimized out>)
at src/client/pscamera.cpp:918
918 result = sector→HitBeamPortals( vo, end );
(gdb) bt
#0 0x0000000000425f2a in psCamera::FindMeshUnder2D (this=0x1130290, x=<value optimized out>, y=758, pos=0x0, poly=<value optimized out>)
at src/client/pscamera.cpp:918
#1 0x00000000005cd38a in psMainWidget::FindMouseOverObject (this=0x2aaab400c9a0, x=-1063952396, y=-1458261536)
at src/client/gui/psmainwidget.cpp:434
#2 0x00000000004053f2 in psEntityLabels::HandleEvent (this=0x109b480, ev=<value optimized out>) at src/client/entitylabels.cpp:418
#3 0x0000000000407f2d in psEntityLabels::EventHandler::HandleEvent (this=<value optimized out>, event=@0x2aaac0955ff4)
at src/client/entitylabels.h:177
#4 0x0000000000570d1d in csEventTree::Dispatch (this=0xb33130, e=@0x2b72019bae4c) at libs/csutil/cssubscription.cpp:576
#5 0x0000000000570dd8 in csEventTree::Notify (this=0xb33130) at libs/csutil/cssubscription.cpp:546
#6 0x0000000000514962 in csEventQueue::Notify (this=0x2b72019e20d4, name=@0x2b72019e224c) at libs/csutil/cseventq.cpp:277
#7 0x0000000000514a21 in csEventQueue::Process (this=0x2b72019e20d4) at libs/csutil/cseventq.cpp:293
#8 0x00000000004bfeb7 in csDefaultRunLoop (r=0x2b72019e7064) at libs/csutil/generic/runloop.cpp:91
#9 0x0000000000477999 in main (argc=<value optimized out>, argv=<value optimized out>) at src/client/psengine.cpp:1878
#10 0x00002b7202656b74 in __libc_start_main () from /lib/libc.so.6
#11 0x0000000000404d19 in _start ()
28.07.2009 09:52
Reason for closing:
Additional comments about closing:
Can't seem to get it to crash anymore,
trunk / trunk.
Vorne, is this still happening?
Hmm, I tried to get it to crash the other day, but it didn't do it… that may be because of the new cs version.
But I'm actually working on that code at the moment, I think the problem starts at FindMouseOverObject(x=-1063952396, y=-1458261536), I will look into this again later when I have more time.
So don't worry about this bug for the present :)
I just got this again, I logged in with a player character, then started another psclient and logged in as a GM, teleported the player character to my location (npcroom1, without clicking the player character's window), logged out of the GM account and back in as another player, about this time the first client segfaulted with a pretty much identical backtrace (I never had the first client's window in view since the start).
This will only happen when the labels are set to show on mouse over, it's because an invalid position is returned for the mouse location, I traced it back to src/common/paws/pawsmanager.cpp:536, there onto CS… I'm not sure if this is a bug that should be fixed in CS, or pawsmouse should check the values are within the accepted range, or FindMeshUnder2D should handle bad numbers gracefully… probably the last.
I had a play, this is what I came up with (though I suspect I'm only showing off my utter noobness :P)
Index: src/client/pscamera.cpp
— src/client/pscamera.cpp (revision 428)
+++ src/client/pscamera.cpp (working copy)
@@ -25,6 +25,7 @@
#include <iengine/movable.h>
#include <iengine/camera.h>
#include <cstool/csview.h>
+#include <igeom/clip2d.h>
#include <ivideo/graph2d.h>
#include <ivideo/graph3d.h>
#include <csutil/flags.h>
@@ -895,7 +896,9 @@
iMeshWrapper* psCamera::FindMeshUnder2D(int x, int y, csVector3 *pos, int *poly)
{
- if (!GetICamera())
+ const csVector2 *csVPos = new csVector2( static_cast<float>(x), static_cast<float>(y) );
+
+ if ( !GetICamera() || !GetView()→GetClipper()→IsInside( *csVPos ) )
I have not had the time to test if that actually fixes it either…
Can't confirm. I tried this:
-Logged in as player.
-Logged in as GM.
-Teleported player to GM in NPCroom1.
-Logged out as GM.
-Logged in as another player. (Really can't see the use of this step).
No crashes, the first player's window remained out of focus at all times.
The crash happens as part of the label drawing code… you must have it set to 'mouse over'. Somehow a label updating event needs to be sent while the window is not in focus, which sometimes returns invalid values for the mouse pointer location.
Probably it does not return an invalid value under Windows.
I had it set to "mouse over" while testing. To make sure the label code was activated I aimed my mouse pointer at an NPC. With the other client, I then walked between the NPC and the first character so that the first client would "see" my second character, evaluate if it was under the mouse pointer, and then attempt to display a label. As I reported before, this led to no crashes.
Can somebody else in Linux attempt to reproduce this?
Well, I got it again…
I was in third person mode, running around after TribeMember, holding down middle mouse button for mouse look, labels set to mouse over, in 1024x768 windowed mode, screen resolution 1152x864…
when the cursor disappeared and my character started running in wide circles, no keys seemed to work. I tried Alt-Tab a few times, nothing happened at first, then it started switching apps very fast for a while, after some button mashing it all returned to normal. This was in the psclient output:
235851) <src/client/pscamera.cpp:917 FindMeshUnder2D>
235961) Bad Values for x and y! 1123,630
because I changed the code like I said above:
Index: games/planeshift/trunk/src/client/pscamera.cpp
— games/planeshift/trunk/src/client/pscamera.cpp (revision 636)
+++ games/planeshift/trunk/src/client/pscamera.cpp (working copy)
@@ -28,6 +28,7 @@
#include <iengine/camera.h>
#include <iengine/engine.h>
#include <cstool/csview.h>
+#include <igeom/clip2d.h>
#include <ivideo/graph2d.h>
#include <ivideo/graph3d.h>
#include <csutil/flags.h>
@@ -908,9 +909,19 @@
iMeshWrapper* psCamera::FindMeshUnder2D(int x, int y, csVector3 *pos, int *poly)
{
- if (!GetICamera())
+ const csVector2 *csVPos = new csVector2( static_cast<float>(x), static_cast<float>(y) );
+
+ + if ( !GetView()→GetClipper()→IsInside( *csVPos ) )
+ {
+ Error3("Bad Values for x and y! %d,%d", x, y);
return NULL;
+ }
+
+ if ( !GetICamera() || !GetView()→GetClipper()→IsInside( *csVPos ) )
+ return NULL;
+
(I know it's repeated and the camera check should be done first, but I just added it for debugging info)
So this is not exactly the same as the original report, those times the window was not in view and the mouse postion, I don't seem to have listed here, but something out of range like -339832879,32140153. This time the window was in focus, and the mouse position returned (1123,630) was within the screen size (1152,864) but not within the ps window size (1024,768).
So it is possible that this is a linux crystalspace bug (sometimes mouse events are sent with invalid values), as pawsmouse just uses whatever values it gets. Or maybe the values could be checked first? Like this maybe, instead of the patch I suggested above:
edit: oopsie, that code crashes psclient on start…
So that would make it ignore values outside of the clipping region, but I don't know if it would slow the game down though.
Ok, let's see if I understand everything.
The problem seems to occur just on Linux, but Vorrne has modified the code as above and that is not helping (not even making start the client).
Right?
Can't somebody else on Linux try to reproduce this!?
Even though you get it often - it is just to narrow the problem to be really just on Linux.
Or, if I have misunderstood everything, please forgive me
Well, after trying lots of things to make sure the mouse values were sane, I used debug messages instead of gdb:
all the times I did it before it had something like "FindMouseOverObject (this=0x2aaab400c9a0, x=-1063952396, y=-1458261536)", but after I added the debug code it was suddenly correct, "FindMouseOverObject (this=0xd4df20, x=592, y=767)". Something funny about gdb, I won't believe it so quickly next time ;)
So it looks like it must be something else. I noticed from the crystal space api docs:
virtual csSectorHitBeamResult iSector::HitBeamPortals( const csVector3 & start, const csVector3 & end )
This function correctly traverse portals and space warping portals. Normally the sector you call this on should be the sector containing the 'start' point.
Maybe since it only happens when the player changes sector, that the sector called with does not contain the start point. Here is some gdb output in case it helps: http://pastebin.ca/847913
I'm lost now…
Re-verified with svn trunk revision 1008.
Prerequisites:
Linux, possibly 64 bit.
Psclient in windowed mode.
Entity labels set always on, or on mouseover.
Procedure:
Start two clients, get both into the game.
Teleport one client to a different map than the other.
Teleport character of the hidden client to the current character
For example:
Login vengeance and guest, both in NPCroom.
'/teleport me npcroom2' as vengeance.
Without ever switching to the guest client, do '/teleport guest here'
Wait.
Guest's client crashes, every time: http://www.pastebin.ca/921381
I've just tried out this bug with trunk and can confirm it with exactly the procedure Vornne described in his last comment.
My system is: (K)Ubuntu 32 bit, 1680x1050, windowed mode, labels always visible.
Full backtrace available here: http://www.pastebin.ca/1175967
It's been a while… thanks neXyon
Vorne, is this still happening? There have been many changes. We switched to trunk CS, there have been changes to HitBeamPortal stuff, targeting now works better, etc.
Also, was the thing to get this reproduced:
1. have labels on mouse over
2. use mouse look by pressing middle mouse button
3. move mouse over label?
Can I get this tested again?