[SERVER-16268] 2.8 Dumps stacktrace when stopped with Control^C Created: 21/Nov/14  Updated: 10/Dec/14  Resolved: 21/Nov/14

Status: Closed
Project: Core Server
Component/s: Internal Code
Affects Version/s: 2.8.0-rc0
Fix Version/s: None

Type: Bug Priority: Minor - P4
Reporter: John Page Assignee: Unassigned
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File mongodlog.txt    
Operating System: ALL
Steps To Reproduce:

Start 2.8

hit with a heavy update / write load
hit controlC a few times in the window you started it in.

Participants:

 Description   

mongod(_ZN5mongo15printStackTraceERSo+0x29) [0xf6ffb9]
mongod(_ZN5mongo10logContextEPKc+0xE1) [0xf17fb1]
mongod(_ZN5mongo11msgassertedEiPKc+0xAF) [0xefe2cf]
mongod(_ZN5mongo8DataFile15allocExtentAreaEPNS_16OperationContextEi+0xCE) [0xd3b32e]
mongod(_ZN5mongo19MmapV1ExtentManager19_createExtentInFileEPNS_16OperationContextEiPNS_8DataFileEib+0x67) [0xd69c67]
mongod(_ZN5mongo19MmapV1ExtentManager13_createExtentEPNS_16OperationContextEib+0xA3) [0xd6b7b3]
mongod(_ZN5mongo19MmapV1ExtentManager14allocateExtentEPNS_16OperationContextEbib+0x1F9) [0xd6be59]
mongod(_ZN5mongo17RecordStoreV1Base19increaseStorageSizeEPNS_16OperationContextEib+0x47) [0xd6fc67]
mongod(_ZN5mongo19SimpleRecordStoreV111allocRecordEPNS_16OperationContextEib+0x219) [0xd7bff9]
mongod(_ZN5mongo17RecordStoreV1Base13_insertRecordEPNS_16OperationContextEPKcib+0x60) [0xd704b0]
mongod(_ZN5mongo17RecordStoreV1Base12insertRecordEPNS_16OperationContextEPKcib+0x79) [0xd70629]
mongod(_ZN5mongo10Collection15_insertDocumentEPNS_16OperationContextERKNS_7BSONObjEb+0x4E) [0x8fa8ce]
mongod(_ZN5mongo10Collection14insertDocumentEPNS_16OperationContextERKNS_7BSONObjEb+0x70) [0x8fb1c0]
mongod(_ZN5mongo18WriteBatchExecutor13execOneInsertEPNS0_16ExecInsertsStateEPPNS_16WriteErrorDetailE+0x2AB) [0x99f79b]
mongod(_ZN5mongo18WriteBatchExecutor11execInsertsERKNS_21BatchedCommandRequestEPSt6vectorIPNS_16WriteErrorDetailESaIS6_EE+0x239) [0x99fc29]
mongod(_ZN5mongo18WriteBatchExecutor11bulkExecuteERKNS_21BatchedCommandRequestEPSt6vectorIPNS_19BatchedUpsertDetailESaIS6_EEPS4_IPNS_16WriteErrorDetailESaISB_EE+0x34) [0x9a10b4]
mongod(_ZN5mongo18WriteBatchExecutor12executeBatchERKNS_21BatchedCommandRequestEPNS_22BatchedCommandResponseE+0x3A5) [0x9a17c5]
mongod(_ZN5mongo8WriteCmd3runEPNS_16OperationContextERKSsRNS_7BSONObjEiRSsRNS_14BSONObjBuilderEb+0x169) [0x9a3919]
mongod(_ZN5mongo12_execCommandEPNS_16OperationContextEPNS_7CommandERKSsRNS_7BSONObjEiRSsRNS_14BSONObjBuilderEb+0x34) [0x9bdf84]
mongod(_ZN5mongo7Command11execCommandEPNS_16OperationContextEPS0_iPKcRNS_7BSONObjERNS_14BSONObjBuilderEb+0xCA1) [0x9bee61]
mongod(_ZN5mongo12_runCommandsEPNS_16OperationContextEPKcRNS_7BSONObjERNS_11_BufBuilderINS_16TrivialAllocatorEEERNS_14BSONObjBuilderEbi+0x222) [0x9bf932]
mongod(_ZN5mongo11newRunQueryEPNS_16OperationContextERNS_7MessageERNS_12QueryMessageERNS_5CurOpES3_b+0x105B) [0xbc0e3b]
mongod(_ZN5mongo16assembleResponseEPNS_16OperationContextERNS_7MessageERNS_10DbResponseERKNS_11HostAndPortEb+0xBC3) [0xaa5483]
mongod(_ZN5mongo16MyMessageHandler7processERNS_7MessageEPNS_21AbstractMessagingPortEPNS_9LastErrorE+0xE0) [0x7e82b0]
mongod(_ZN5mongo17PortMessageServer17handleIncomingMsgEPv+0x421) [0xf2c691]
libpthread.so.0(+0x7F18) [0x7f3517a42f18]
libc.so.6(clone+0x6D) [0x7f3516b54b9d]



 Comments   
Comment by Eric Milkie [ 21/Nov/14 ]

It was actually possible to get a stack trace in 2.6 as well, depending on your workload. For developer and training scenarios, are users commonly shutting down servers that are under heavy load?
Longer term, we are considering not having massert print stack traces, as they are not useful for support.

Comment by John Page [ 21/Nov/14 ]

It means we will have a lot of customers see stack traces - this didn't happen in 2.6 so it may well work as designed but it looks broken.
Control-C isn't how a production system works but common in developer and training scenarios.

Comment by Eric Milkie [ 21/Nov/14 ]

Thanks.
What you are seeing is the behavior of massert. Typically these are used to end an operation after the detection of some bad situation on the server, as opposed to an error that a database user triggered. Since shutting the server down directly on the process with Ctrl-C is server-only (as opposed to running the Shutdown command via an external database connection), massert is appropriate to see here.

Comment by John Page [ 21/Nov/14 ]

Attached Log copied and pasted from terminal window. wasnt being logged to a file, sorry.

Comment by Eric Milkie [ 21/Nov/14 ]

Can you attach the full log?

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