[SERVER-17359] Uncaught alloc Exception in Snappy on Windows Created: 23/Feb/15  Updated: 27/Apr/15  Resolved: 24/Feb/15

Status: Closed
Project: Core Server
Component/s: Storage, WiredTiger
Affects Version/s: 3.0.0-rc9
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Robert Guo (Inactive) Assignee: Michael Cahill (Inactive)
Resolution: Won't Fix Votes: 0
Labels: 28qa
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows Server 2012 R2


Backwards Compatibility: Fully Compatible
Operating System: Windows
Steps To Reproduce:

manually throw a std::bad_alloc() in place of

    if (scratch_output == NULL) {
      scratch_output = new char[max_output];
    }

around line 945 in snappy.cc.

We may need to keep a counter to only throw after 50 or so calls, otherwise WT won't start.

Participants:

 Description   

snappy.cc could throw an exception if an allocation for a char array fails in the function "Compress". This exception is not caught.

There's a code review for a different change that affects this line of code but does not address this issue.
link to CR here: http://codereview.10gen.com/6078463630901248/patch/5629499534213120/5066549580791808
link to SERVER ticket here: SERVER-17299

This only affects Windows since other OSes don't use this function.

mongod log is attached in the comments



 Comments   
Comment by Michael Cahill (Inactive) [ 24/Feb/15 ]

robert.guo, this is a real issue, but it can't be fixed in WiredTiger: we are calling a C API, it shouldn't throw exceptions. Can you follow up with the snappy maintainers to have them address this? Thanks.

Comment by Michael Cahill (Inactive) [ 24/Feb/15 ]

The only place where that exception can reasonably be caught is in the snappy_compress function in the C API for snappy that WiredTiger uses. We could make that change in MongoDB's copy of the Snappy code, but this issue would really be better addressed to the snappy maintainers:

https://code.google.com/p/snappy/issues/list

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