Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Recurring crash around 20000GF #447

Closed
davidstenstroem opened this issue Apr 10, 2016 · 5 comments
Closed

Recurring crash around 20000GF #447

davidstenstroem opened this issue Apr 10, 2016 · 5 comments

Comments

@davidstenstroem
Copy link

I've been experiencing a recurring crash on all maps around 20000GF. It doesn't matter if it is a map with searoutes or without it. Also, it doesn't seem to matter what settings I'm playing with.
It says this in the terminal:

Sucessfully connected to debug.rttr.info:4123
Sending replay...
- Replay length: 42114
- Compressing...
- Sending...
-> success
Will now send 27 stack frames
/Users/David/Desktop/s25client.app/Contents/MacOS/rttr.command: line 63: 53707 Abort trap: 6           ./bin/s25client

I'm on OSX 10.11.4
EDIT: I just noticed bug #333 - mine seems to be related, as it is the same console output

@Flamefire
Copy link
Member

The output is just from sending the debug data. So it is after the crash and tells nothing about the crash itself.
What would be interesting to know: Do you have autosave enabled? Does the replay crash on the same position every time? Which GF is shown last before it crashes?

@Flamefire Flamefire added this to the 0.8.3 - bugfixes milestone Apr 10, 2016
@Flamefire Flamefire self-assigned this Apr 10, 2016
@Flamefire
Copy link
Member

Ok I could reproduce this with the replay send in 20160410_105743... which goes to GF 9181 and crashes on the very next GF.
It does not happen with natively compiled s25client, even when this is placed in the rttr folder (only client replaced)

The stacktrace is this:

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x00007fff81d32002 pthread_kill + 10
1 libsystem_pthread.dylib 0x00007fff8600c5c5 pthread_kill + 90
2 libsystem_c.dylib 0x00007fff8fc196e7 abort + 129
3 s25client 0x0000000100061417 LinExceptionHandler(int) + 172
4 ??? 0xbff0000000000000 0 + 13830554455654793216
5 com.apple.CoreFoundation 0x00007fff933a670c __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER
+ 12
6 com.apple.CoreFoundation 0x00007fff933a667f ___CFXRegistrationPost_block_invoke + 63
7 com.apple.CoreFoundation 0x00007fff933a5d47 _CFXRegistrationPost + 407
8 com.apple.CoreFoundation 0x00007fff933a5ab2 ___CFXNotificationPost_block_invoke + 50
9 com.apple.CoreFoundation 0x00007fff9339fd42 -[_CFXNotificationRegistrar find:object:observer:enumerator:] + 1922
10 com.apple.CoreFoundation 0x00007fff9328e145 _CFXNotificationPost + 693
11 com.apple.Foundation 0x00007fff91c3d921 -[NSNotificationCenter postNotificationName:object:userInfo:] + 66
12 com.apple.AppKit 0x00007fff884be65d -[NSApplication _postDidFinishNotification] + 297
13 com.apple.AppKit 0x00007fff884be3d3 -[NSApplication sendFinishLaunchingNotification] + 203
14 com.apple.AppKit 0x00007fff884bb88d -[NSApplication(NSAppleEventHandling) handleAEOpenEvent:] + 557
15 com.apple.AppKit 0x00007fff884bb337 -[NSApplication(NSAppleEventHandling) handleCoreEvent:withReplyEvent:] + 250
16 com.apple.Foundation 0x00007fff91c6f861 -[NSAppleEventManager dispatchRawAppleEvent:withRawReply:handlerRefCon:] + 290
17 com.apple.Foundation 0x00007fff91c6f6db NSAppleEventManagerGenericHandler + 102
18 com.apple.AE 0x00007fff810bd231 aeDispatchAppleEvent(AEDesc const
, AEDesc
, unsigned int, unsigned char
) + 531
19 com.apple.AE 0x00007fff810bcfb8 dispatchEventAndSendReply(AEDesc const
, AEDesc*) + 31
20 com.apple.AE 0x00007fff810bced4 aeProcessAppleEvent + 288
21 com.apple.HIToolbox 0x00007fff8b04faf9 AEProcessAppleEvent + 55
22 com.apple.AppKit 0x00007fff884b5588 _DPSNextEvent + 2245
23 com.apple.AppKit 0x00007fff88881943 -[NSApplication _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 454
24 com.apple.AppKit 0x00007fff884aafc8 -[NSApplication run] + 682
25 s25client 0x0000000100012e23 CustomApplicationMain + 408
26 s25client 0x000000010001325a main + 240
27 s25client 0x0000000100012165 _start + 227
28 s25client 0x0000000100012081 start + 33

It seems to crash after __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ which is some apple specific notification stuff which I don't know where we could trigger this. Maybe @Flow86 got any ideas?

@Flamefire Flamefire removed their assignment Apr 10, 2016
@Flamefire
Copy link
Member

So it seems to be a problem with the build-server. This is something @Flow86 should work out. What I found is some differences in the loaded libraries:

Buildserver:

/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 12.0.0)
/usr/lib/libbz2.1.0.dylib (compatibility version 1.0.0, current version 1.0.5)
@executable_path/../Frameworks/SDL.framework/Versions/A/SDL (compatibility version 1.0.0, current version 1.0.0)
libminiupnpc.5.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.4.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.4)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 227.0.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 476.19.0)
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 34.0.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 677.26.0)
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 949.54.0)

Native Build:

/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 22.0.0)
/usr/lib/libbz2.1.0.dylib (compatibility version 1.0.0, current version 1.0.5)
/usr/local/opt/sdl/lib/libSDL-1.2.0.dylib (compatibility version 12.0.0, current version 12.4.0)
/usr/local/opt/miniupnpc/lib/libminiupnpc.15.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.1.0)

/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1256.14.0)
/System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics (compatibility version 64.0.0, current version 600.0.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1256.1.0)
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 1404.34.0)

Besides the version differences we have ApplicationServices instead of CoreGraphics in the build server version. Maybe it is also caused by the old Cocoa version.

@Flow86
Copy link
Member

Flow86 commented Apr 10, 2016

the library differences should not be the problem - any "align-double"-problematic (aka compiler flags) again?

@Flamefire
Copy link
Member

Good idea. I've seen the build server disables optimizations with -O0. Done this locally -> Crash. Trying to find the reason for this...

Edit: Found something: in noFigure::Wander it calls gwg->GetPointsInRadius<0>(pos, wander_radius, Point2Flag(*gwg), IsValidFlag(player)); but does not take the correct Point2Flag struct but the one from AIConstruction.cpp. This seems to be a compiler bug as it should be impossible to happen...
But Backtrace clearly shows this:

thread #1: tid = 0x1df45, 0x00007fff82a56b1e libc++abi.dylib`__dynamic_cast + 34, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
frame #0: 0x00007fff82a56b1e libc++abi.dylib`__dynamic_cast + 34
frame #1: 0x000000010029be93 s25client`noFlag const* World::GetSpecObj<noFlag>(this=0x0000000100be2938, pt=<unavailable>) const + 115 at World.h:185
frame #2: 0x000000010028e590 s25client`noFlag const* AIInterface::GetSpecObj<noFlag>(this=0x00000001014d8710, pt=<unavailable>) const + 48 at AIInterface.h:120
frame #3: 0x000000010029c524 s25client`Point2Flag::operator(this=0x00007fff5fbfc698, pt=<unavailable>, (null)=2)(Point<unsigned short>, unsigned int) const + 52 at AIConstruction.cpp:194
frame #4: 0x000000010059467b s25client`std::__1::vector<Point2Flag::result_type, std::__1::allocator<Point2Flag::result_type> > World::GetPointsInRadius<0u, Point2Flag, IsValidFlag>(this=0x00000001014d8700, pt=<unavailable>, radius=10, transformPt=Point2Flag @ 0x00007fff5fbfc698, isValid=(playerId_ = 0)) const + 811 at World.h:303
frame #5: 0x000000010058ca94 s25client`noFigure::Wander(this=0x00000001160687a0) + 308 at noFigure.cpp:612

Edit: Reason was that both have the same name. -O3 inlines them so no problem anymore, but otherwise they should refer to the same struct/code... Interesting that it does not throw an error about duplicate definition though...

Changing the name fixes the crash O.o @Flow86 Do you know the reason why -O0 was used? Comment only states gcc bug

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants