[vishnu]

Old timers hereabout may remember that I've been attempting to recreate Julian Braun's 21 (blackjack) simulations that were published in Lawrence Revere's book "Playing Blackjack as a Business." I've been running variants of this code for years but today it's started crashing in the C++ vector allocation. It makes me wonder if I've got failing hardware, but nothing else on my system is crashing. Running it in Valgrind or gdb tells me where it's crashing, but not why. For example Valgrind says "Conditional jump or move depends on uninitialised value(s)" - to where I'm like well, the simulation just ran through over a thousand loops of the exact same code, so why is it wrong now? Anyway, attached is a much-simplified version of the simulation, don't pay any attention to what the gui says (only the first 5 lines are hooked up), if any of you kind souls would be willing to give it a try and let me know if the vector objects are crashing I'd be ever so grateful! I'm compiling it with gcc 10.2.0 (optimization doesn't prevent the crash) and Motif 2.1.32 (although the exact version of Motif shouldn't matter):

g++ -ggdb -Wall -pedantic -W -lXm -lXt -lX11 -lXmu -o arrays-5 arrays-5.cpp

Don't worry about the compiler warnings, they are meaningless. If you run it in gdb and it crashes in vector you should see something like this in the backtrace (image attached)    

[jpstewart]

I compiled it on a machine with an older GCC 8.3.0 installation for comparison sake, and got the same crash.

[Raion]

I'll check if this has a similar crash on FreeBSD with GCC.

[jwhat]

Hi vishnu,

on Ubuntu 20.04 (x86_64) KVM/QEMU VM:

>> sudo apt install libx11-dev libxmu-dev libmotif-dev
>> g++ -ggdb -pedantic -W -o arrays-5 arrays-5.cpp -lXm -lXt -lX11 -lXmu

Got grid of results which are all zeros ... but it did not crash



I had to remove the -Wall flag as it failed to link with this and had to put input before link library list to avoid unresolved symbols ...

Same result with -d flag or not

EDIT: Adjusted UI resolution to allow full display and running of simulations

Cheers from Oz,

jwhat/John.

[jpstewart]

I did some more testing this morning on a different box with GCC 10.2.1.  Like jwhat, I had to re-order the command line to put the cpp input file ahead of the libraries.  Unlike him, the -Wall flag didn't cause any problems for me.

However, I noticed that it only segfaults sometimes.  It looks to be when the player is dealt a pair of cards and you enter one of the "if" blocks starting at line 808 of the source .cpp file that it falls apart.  No pair, no segfault.

@jwhat:  in your screenshot the GUI looks truncated at row 16.  It should go to 19, then have a "Totals" row, and below that "sim" and "reset" buttons.  Did you click the "sim" button (which may have been off your screen) to run the simulation?  It's only after doing that, that I (sometimes) see it segfault.  It will also output a ton of info in the launching terminal while it runs.

[vishnu]

Well, the thing is I took out all the code after the pair of fives (just to make it a simpler thing for this discussion), and yes it only segfaults sometimes because I changed the number of simulation runs from 100000 (to 1989) in the inner loop and 40 (to 2) in the outer loop, because Braun's simulation was for 100000 hands and I found I have to run that sim at least 40 times to get the same numbers Braun got. If you make those changes to the loops it segfaults every time. But what's weird is, I've been running variants of this code for years and never had this problem with segfaults before. There's a whole crapton of other code that I removed for simplicity, for example I keep the results of each of the 340 combinations in vectors as well, and then average them at the end of the 40 loops through 100000 dealt hands to match Braun's results...

EDIT: Okay I just tried jwhat's compile line and he's right, it does appear to prevent the segfaults, amazing, and THANKS! Not sure HOW it makes a difference but it sure does. I'm pretty sure I would never have thought to try that on my own... 0_o

EDIT2: I just changed the inner loop back to 100000 and it's crashing again every time. =(

Anyway, thanks for looking at this guys!

---

Most recent crash, the player's card can never be a zero and the size of discards can never be more than 52 if the code runs correctly:
Size of shoe is 0
Size of discards is 69414180

Shuffling, sim number 65541

Size of shoe 52
Size of discards 0

Player's first card is a  0

Program received signal SIGSEGV, Segmentation fault.
0x0000000000408f61 in __gnu_cxx::new_allocator<unsigned short>::construct<unsigned short, unsigned short>/c++/10.2.0/ext/new_allocator.h:150
150  { ::new((void *)__p) _Up(std::forward<_Args>(__args)...); }

EDIT3: At this point I think it's time for a post to the GNU C++ library mailing list, I didn't want to do that until I knew it would crash on other people's workstations, so not to repeat myself or anything, but thanks guys!   

EDIT4: I commented out all the code in the show_data function and now it's doing 40 passes of 100,000 hands each without ever crashing, so is it a Motif problem? I don't get it because the segfaults are in the new allocator and nothing in that function allocates anything...

EDIT5: Okay I think I fixed it, I moved the variables XExposeEvent xev and Dimension ww, hh back into the show_results function (I had made them global because I didn't want them redeclared all the 4,000,000 times that function is called, even though I was pretty sure the compiler would optimize for that if I didn't make them global). I have no idea how their being global could be causing a problem in the new allocator, but anyway sorry for the bother guys!

[jwhat]

Hi Vishnu,

is code checking for allocation failure ?

I have been writing AI search space stuff which can result in combinatorial explosion, which in turns results in allocation requests that are to big to succeed.

So I had to put in test for integer overflow and memory allocation checks.

Then increased VM memory and the allocated Java heap size.

I still get combinatorial explosion, with 1 extra iteration of search (due to memory increase), but now fail gracefully ;-)

Wondering if your code is having similar problem (heap is heap, irrespective of Java or C++).

No smarts in shuffling compile line, as I could not link without that.

Also the window was cut off in my case due to vm display size. Out of curiosity I will make it bigger so I can see the entire thing.

Cheers from Oz,

jwhat/John

[vishnu]

Thanks John, but if you look at EDIT5 in my post just above yours you'll see it's fixed now. However, that doesn't mean I'm not still completely befuddled by how having an X event and two X dimension variables be global, and only be used in that function, a function which doesn't execute any C++ code, could somehow cause an allocation failure in vector. That said, I 100 percent realize that using globals is almost never a good idea. But, on the other hand, if you look at the demos that come with Motif, they almost all use globals...

[jpstewart]

Thanks, vishnu, for sharing your adventures. It's been interesting to speculate about what's going on. I'm glad you've got it working!

[vishnu]

Thanks, vishnu, for sharing your adventures.  It's been interesting to speculate about what's going on.  I'm glad you've got it working!

Thanks to you guys for helping me look into it! I'll post the entire program once I have it polished a bit more...