[SERVER-23460] "error: offset outside bounds of constant string" compiling src/mongo/bson/bson_obj_test.cpp Created: 01/Apr/16  Updated: 04/Apr/16  Resolved: 04/Apr/16

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

Type: Bug Priority: Major - P3
Reporter: Michael Hudson-Doyle Assignee: Jonathan Reams
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVER-23465 Make master compile cleanly with gcc 5.3 Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Steps To Reproduce:

ubuntu@promonarchy-remi:~/mongo$ g++ -c -O2 -Werror -std=c++11 -Ibuild/opt -Isrc src/mongo/bson/bson_obj_test.cpp 
In file included from src/mongo/db/jsobj.h:49:0,
                 from src/mongo/bson/bson_obj_test.cpp:28:
src/mongo/bson/bsonelement.h: In member function ‘virtual void {anonymous}::UnitTest__BSONObj__getFields::_doTest()’:
src/mongo/bson/bsonelement.h:236:23: error: offset outside bounds of constant string [-Werror]
         return data + 1;
                       ^
cc1plus: all warnings being treated as errors

Sprint: Platforms 13 (04/22/16)
Participants:

 Description   

This is a bit strange and it might be a compiler bug. but if you try to build mongodb on Ubuntu Xenial you get this problem. The smallest version of the code I've managed to find is http://paste.ubuntu.com/15573440/. I haven't tried using gcc tip yet, that's probably one of the next things to try.

It happens with 3.2 and git tip.



 Comments   
Comment by Jonathan Reams [ 04/Apr/16 ]

We've pushed support for gcc 5.3.0 to master, so I'm resolving this as a duplicate of SERVER-23465.

Comment by Michael Hudson-Doyle [ 02/Apr/16 ]

Ah, I can confirm that fixes the warning, thanks! I'll pull that patch or something like it into our packaging (this is for the special juju-mongodb packages we make; I don't think there are debian or ubuntu packages of mongodb 3.2 yet).

For the record, the warning also happens with the version of g++ on 15.10 ("g++ (Ubuntu 5.2.1-22ubuntu2) 5.2.1 20151010"), that on 16.04 ("g++ (Ubuntu 5.3.1-13ubuntu3) 5.3.1 20160330") and a gcc tip as of yesterday ("g++ (GCC) 6.0.0 20160401 (experimental)"), although the tip one doesn't warn on the reduced paste from that pastebin.

Thanks for the quick reply!

Comment by Mira Carey [ 01/Apr/16 ]

We've come across this in our efforts to get the server compiling with gcc 5.3 without warnings. The problem seems to be with the way we create default constructed bsonelements:

inline BSONElement::BSONElement() {
    static const char kEooElement[] = "";
    data = kEooElement;
    fieldNameSize_ = 0;
    totalSize = 1;
}

Note that we're setting data to be a single 0 byte. In actual runtime practice we always check the byte under data (to check for eoo) before reading any bytes thereafter, but it seems that gcc doesn't believe that. The error in question is occurring because kEooElement + 1 isn't a valid pointer.

The fix we're considering is:

Index: src/mongo/bson/bsonelement.h
diff --git a/src/mongo/bson/bsonelement.h b/src/mongo/bson/bsonelement.h
index 8b53bb83dfdc30eaac5d4012cd5560753b23fe1e..97d8054f65b8f5a8ab3cf0a81464732303cfebf0 100644
--- a/src/mongo/bson/bsonelement.h
+++ b/src/mongo/bson/bsonelement.h
@@ -802,7 +802,10 @@ inline long long BSONElement::safeNumberLong() const {
 }
 
 inline BSONElement::BSONElement() {
-    static const char kEooElement[2] = { 0, 0 };
+    // This needs to be 2 elements because the we check the strlen of data + 1 and GCC sees that
+    // as accessing beyond the end of a constant string, even though we always check whether the
+    // element is an eoo.
+    static const char kEooElement[2] = { '\0', '\0' };
     data = kEooElement;
     fieldNameSize_ = 0;
     totalSize = 1;

And the ticket where we'll be commiting that fix is: SERVER-23465.

Comment by Andrew Morrow (Inactive) [ 01/Apr/16 ]

Also, curious about your paste (and thanks a ton for making a small example, that is much appreciated). Does the bug still occur if:

  • If you comment out line 20 and 21, leaving just the declaration of 'elem'?
  • Do you need both line 20 and 21 to trigger the bug? Does it happen on both of them? Does it happen if you only have one or the other?
  • I notice that the optimization level changes whether the error is reported, but that just may be that aggressive inlining at O2 is letting the compiler see the flow of constants deeper, and it is actually reporting a real issue.

I wonder if we can start to unravel the comparison functions a bit, and see if the example can be reduced further.

Comment by Andrew Morrow (Inactive) [ 01/Apr/16 ]

Hi mwhudson - What version of GCC is on Xenial? I don't happen to have it installed to try to repro.

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