[SERVER-6886] mongoexport gets Assertion: 10320:BSONElement: bad type -100 after shudown and recovery using journaling Created: 29/Aug/12  Updated: 14/Mar/13  Resolved: 12/Mar/13

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

Type: Bug Priority: Major - P3
Reporter: Jin Hwa Kim Assignee: Stephen Lee
Resolution: Incomplete Votes: 0
Labels: mongoexport
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

CentOS release 5.7 (Final)


Operating System: Linux
Participants:

 Description   

standalone mongod with journaling was turned off, and restarted with automatic recovery.
but when using mongoexport, it splits out the assertion 10320 and can't have the job done successfully.

Wed Aug 29 14:41:24 Assertion: 10320:BSONElement: bad type -100
0x581222 0x50464b 0x513249 0xaa3c0f 0xa9ca9d 0xaa0702 0x3598a1d994 0x4fe4f9
/home/mongodb-linux-x86_64-2.0.7/bin/mongoexport(_ZN5mongo11msgassertedEiPKc+0x112) [0x581222]
/home/mongodb-linux-x86_64-2.0.7/bin/mongoexport(_ZNK5mongo11BSONElement4sizeEv+0x1cb) [0x50464b]
/home/mongodb-linux-x86_64-2.0.7/bin/mongoexport(_ZNK5mongo7BSONObj10jsonStringENS_16JsonStringFormatEi+0x1d9) [0x513249]
/home/mongodb-linux-x86_64-2.0.7/bin/mongoexport(_ZN6Export3runEv+0x11bf) [0xaa3c0f]
/home/mongodb-linux-x86_64-2.0.7/bin/mongoexport(_ZN5mongo4Tool4mainEiPPc+0x169d) [0xa9ca9d]
/home/mongodb-linux-x86_64-2.0.7/bin/mongoexport(main+0x32) [0xaa0702]
/lib64/libc.so.6(__libc_start_main+0xf4) [0x3598a1d994]
/home/mongodb-linux-x86_64-2.0.7/bin/mongoexport(__gxx_personality_v0+0x3c9) [0x4fe4f9]
assertion: 10320 BSONElement: bad type -100

I did repair database, and solved that problem.



 Comments   
Comment by Stephen Lee [ 12/Mar/13 ]

Thanks for trying to reproduce the issue again. I'm going to resolve this as incomplete, but feel free to reopen if you experience the problem again.

Comment by Jin Hwa Kim [ 11/Mar/13 ]

I moved the job, so data and command-line are unavailable, sadly.

I think the mongoexport command was simple, exporting the whole database as JSON format.

Sorry for not helpful description but it was too long ago to track down.

Comment by Stephen Lee [ 11/Mar/13 ]

No problem on the miscommunication, Jin.

The "bad type" error sometimes indicates data corruption, especially if a database repair seems to "workaround" the issue.

Could you share the syntax of the mongoexport command which causes the "bad type" error? If you can reproduce it again, can you try a similar mongodump of the database(s) that you're trying to output? I'd like to see if the issue is isolated to mongoexport or not.

If you can run mongodump without error and if the data isn't sensitive, could you post the data to the ticket? Let me know if the data's sensitive, and we can arrange an alternative means for sending us the relevant data to debug further.

Comment by Jin Hwa Kim [ 08/Mar/13 ]

@Stephen Lee, sorry for my description's ambiguity, journaling had been always turned on.

standalone instance whose journaling was enabled was turned off by shutdown or being killed. And when it had been restarted, there was no error for its auto-recovery of journaling.

It was seemed to be normal, however, when I tried to mongoexport, above the error was generated.

The point is journaling works fine for its auto-recovery when it restarted, but mongoexport needs database repair operation after crush even journaling has been on.

Comment by Stephen Lee [ 08/Mar/13 ]

Hi Jin,

If journalling is disabled and mongoexport works correctly after a db.repairDatabase(), it's possible that you had some corrupt data, which triggered the original "bad type -100" error. Is there a reason why you disabled journalling?

-Stephen

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