[SERVER-11570] mongo crashes on quit Created: 05/Nov/13  Updated: 11/Jul/16  Resolved: 06/Dec/13

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: 2.4.8
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Patrick Perroud Assignee: Tyler Brock
Resolution: Done Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

macports on mavericks


Operating System: OS X
Steps To Reproduce:

1- Install 2.4.8 MacPort on Mavericks OS X.
2 - Start mongo from a terminal.
3 - Switch db then process a full bentch of db.collection.find()
4 - Quit mongo by Ctrl-D key - mongo is crashing consistently on exit

See 3 examples below (each starting with "bye"):

bye
Mon Nov 4 15:14:02.065 mongo got signal 11 (Segmentation fault: 11), stack trace:

Mon Nov 4 15:14:02.215 0x10430da2a 0x10420da2a 0x7fff8fec55aa 0xa 0x10438d6c7 0x10445acc9 0x10445ab31 0x1042cb4ad 0x1042cb35f 0x1042149ab 0x104214fbf 0x7fff8908b5fd
0 mongo 0x000000010430da2a ZN5mongo15printStackTraceERNSt3_113basic_ostreamIcNS0_11char_traitsIcEEEE + 58
1 mongo 0x000000010420da2a _Z12quitAbruptlyi + 666
2 libsystem_platform.dylib 0x00007fff8fec55aa _sigtramp + 26
3 ??? 0x000000000000000a 0x0 + 10
4 mongo 0x000000010438d6c7 _ZN2v88internal15DeoptimizerDataD1Ev + 55
5 mongo 0x000000010445acc9 _ZN2v88internal7Isolate6DeinitEv + 105
6 mongo 0x000000010445ab31 _ZN2v88internal7Isolate8TearDownEv + 81
7 mongo 0x00000001042cb4ad _ZN5mongo7V8ScopeD2Ev + 285
8 mongo 0x00000001042cb35f _ZN5mongo7V8ScopeD0Ev + 15
9 mongo 0x00000001042149ab Z5_mainiPPcS0 + 22507
10 mongo 0x0000000104214fbf main + 95
11 libdyld.dylib 0x00007fff8908b5fd start + 1

bye
Mon Nov 4 17:49:39.573 mongo got signal 11 (Segmentation fault: 11), stack trace:

Mon Nov 4 17:49:39.575 0x10c757a2a 0x10c657a2a 0x7fff8fec55aa 0xa 0x10c7d76c7 0x10c8a4cc9 0x10c8a4b31 0x10c7154ad 0x10c71535f 0x10c65e9ab 0x10c65efbf 0x7fff8908b5fd 0x2
0 mongo 0x000000010c757a2a ZN5mongo15printStackTraceERNSt3_113basic_ostreamIcNS0_11char_traitsIcEEEE + 58
1 mongo 0x000000010c657a2a _Z12quitAbruptlyi + 666
2 libsystem_platform.dylib 0x00007fff8fec55aa _sigtramp + 26
3 ??? 0x000000000000000a 0x0 + 10
4 mongo 0x000000010c7d76c7 _ZN2v88internal15DeoptimizerDataD1Ev + 55
5 mongo 0x000000010c8a4cc9 _ZN2v88internal7Isolate6DeinitEv + 105
6 mongo 0x000000010c8a4b31 _ZN2v88internal7Isolate8TearDownEv + 81
7 mongo 0x000000010c7154ad _ZN5mongo7V8ScopeD2Ev + 285
8 mongo 0x000000010c71535f _ZN5mongo7V8ScopeD0Ev + 15
9 mongo 0x000000010c65e9ab Z5_mainiPPcS0 + 22507
10 mongo 0x000000010c65efbf main + 95
11 libdyld.dylib 0x00007fff8908b5fd start + 1
12 ??? 0x0000000000000002 0x0 + 2

bye
Mon Nov 4 20:09:02.678 mongo got signal 11 (Segmentation fault: 11), stack trace:

Mon Nov 4 20:09:02.728 0x103a6ba2a 0x10396ba2a 0x7fff8fec55aa 0xa 0x103aeb6c7 0x103bb8cc9 0x103bb8b31 0x103a294ad 0x103a2935f 0x1039729ab 0x103972fbf 0x7fff8908b5fd
0 mongo 0x0000000103a6ba2a ZN5mongo15printStackTraceERNSt3_113basic_ostreamIcNS0_11char_traitsIcEEEE + 58
1 mongo 0x000000010396ba2a _Z12quitAbruptlyi + 666
2 libsystem_platform.dylib 0x00007fff8fec55aa _sigtramp + 26
3 ??? 0x000000000000000a 0x0 + 10
4 mongo 0x0000000103aeb6c7 _ZN2v88internal15DeoptimizerDataD1Ev + 55
5 mongo 0x0000000103bb8cc9 _ZN2v88internal7Isolate6DeinitEv + 105
6 mongo 0x0000000103bb8b31 _ZN2v88internal7Isolate8TearDownEv + 81
7 mongo 0x0000000103a294ad _ZN5mongo7V8ScopeD2Ev + 285
8 mongo 0x0000000103a2935f _ZN5mongo7V8ScopeD0Ev + 15
9 mongo 0x00000001039729ab Z5_mainiPPcS0 + 22507
10 mongo 0x0000000103972fbf main + 95
11 libdyld.dylib 0x00007fff8908b5fd start + 1

Participants:

 Description   

When I quit mongo shell with a Ctrl-D after a full bench a db queries
fired from the command line, the shell simply crashes on exit with signal
11 error ("Segmentation fault")



 Comments   
Comment by Tyler Brock [ 01/Dec/13 ]

Merged here

Thanks Mike.

Comment by Mike McQuaid [ 01/Dec/13 ]

Thanks Tyler.

Comment by Tyler Brock [ 30/Nov/13 ]

Pull request up here

Comment by Ryan Schmidt [ 29/Nov/13 ]

It's a simple one-line change to backport. We have it in MacPorts.

https://trac.macports.org/browser/trunk/dports/databases/mongodb/files/patch-src-third_party-v8-src-spaces.h.diff?rev=113011

Comment by Mike McQuaid [ 29/Nov/13 ]

Homebrew maintainer here. I'm going to mark it as unsupported with Clang for now. However, as Clang is the only compiler bundler with Xcode 5 or the Apple Developer Command Line Utilities on OSX 10.9 and 10.8 we will be removing software that doesn't support Clang.

If at all possible I'd encourage you to backport the patch. Clang is the default compiler on OSX and has been for a long time at this point.

Comment by Sri Sankaran [ 22/Nov/13 ]

FWIW it happens on MongoDB version 2.4.6 as well (on Mac OS X 10.9 Mavericks)

Comment by Andrew Morrow (Inactive) [ 05/Nov/13 ]

Hi Patrick -

It is the case that 2.4.8 and 2.5.3 are using the same underlying v8 engine, and we have not backported the fix that we applied in 2.5 to the 2.4 branch. That is why you observe it on 2.4.8 even after the change was applied to 2.5.

We are not backporting fixes for clang specific issues to 2.4, since clang was never officially supported for that release series. The specific v8 bug that the patch addresses currently only manifests with clang.

The MacPorts mongodb maintainers may be able to help you, either by specifying in the Portfile that mongodb should be built with GCC, or by including the patch in the Portfile for mongodb if they feel that that is appropriate.

Comment by Patrick Perroud [ 05/Nov/13 ]

After a second thought: if 11099 was fixed on October 18 for 2.5.3 how could it show up again in a 2.4.8 released 2/3 weeks later? Assuming it was the same issue. It's most probably same effects for different causes...

Comment by Patrick Perroud [ 05/Nov/13 ]

Looks pretty much the same to me YES but in my case it was a 2.4 (production) not a 2.5 (development).

What I've noticed in both cases is: both issue seem related to the V8 engive - which makes sense since this is happening in mongo shell - that's built upon V8.

Is there any chance both 2.4.8 and 2.5.3 are using the same V8 code base? Because if this was the case then we might be closer to the cause - don't you think?

Comment by Andrew Morrow (Inactive) [ 05/Nov/13 ]

I believe you are encountering SERVER-11099.

Generated at Thu Feb 08 03:26:10 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.