Possible SDL2/driver issue: double free or corruption

I’m having a problem using SDL2, my programs crash as soon as I attempt to run SDL_Init. I’ve created a minimal test program below to demonstrate this:
#include <SDL.h>

int main() {
  if(SDL_Init(SDL_INIT_VIDEO) < 0)
    printf("Error initialzing. %s", SDL_GetError());

Save as sdlInitTest.cpp and compile with
g++ -I/home/rofer/include/SDL2 -L/home/rofer/lib -Wl,-rpath,/home/rofer/lib sdlInitTest.cpp -lSDL2
(I installed SDL2 into my home)
Run as ./a.out and I get

*** glibc detected *** ./a.out: double free or corruption (fasttop): 0x0000000001ec6ba0 *** [42/522]
======= Backtrace: =========
======= Memory map: ========
If I run it with valgrind I get:
==16220== Memcheck, a memory error detector
==16220== Copyright © 2002-2012, and GNU GPL’d, by Julian Seward et al.
==16220== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==16220== Command: ./a.out
==16220== Invalid free() / delete / delete[] / realloc()
==16220== at 0x4A07786: free (vg_replace_malloc.c:446)
==16220== by 0x3555C459D8: XFree (in /usr/lib64/libX11.so.6.3.0)
==16220== by 0x4CBF13F: X11_VideoInit (SDL_x11video.c:329)
==16220== by 0x4CA60ED: SDL_VideoInit (SDL_video.c:506)
==16220== by 0x4C1FB66: SDL_InitSubSystem (SDL.c:95)
==16220== by 0x4C1FBF7: SDL_Init (SDL.c:193)
==16220== by 0x4007B9: main (in /home/rofer/Code/C++/SDL/LiquidEarth/a.out)
==16220== Address 0x4feac50 is 0 bytes inside a block of size 9 free’d
==16220== at 0x4A07786: free (vg_replace_malloc.c:446)
==16220== by 0x3555C459D8: XFree (in /usr/lib64/libX11.so.6.3.0)
==16220== by 0x4CBF02C: X11_VideoInit (SDL_x11video.c:320)
==16220== by 0x4CA60ED: SDL_VideoInit (SDL_video.c:506)
==16220== by 0x4C1FB66: SDL_InitSubSystem (SDL.c:95)
==16220== by 0x4C1FBF7: SDL_Init (SDL.c:193)
==16220== by 0x4007B9: main (in /home/rofer/Code/C++/SDL/LiquidEarth/a.out)
==16220== Syscall param write(buf) points to uninitialised byte(s)
==16220== at 0x35538E4950: __write_nocancel (in /usr/lib64/libc-2.15.so)
==16220== by 0x3553875FE2: _IO_file_write@@GLIBC_2.2.5 (in /usr/lib64/libc-2.15.so)
==16220== by 0x3553875EC1: new_do_write (in /usr/lib64/libc-2.15.so)
==16220== by 0x3553876D64: _IO_do_write@@GLIBC_2.2.5 (in /usr/lib64/libc-2.15.so)
==16220== by 0x3553876E0F: _IO_file_sync@@GLIBC_2.2.5 (in /usr/lib64/libc-2.15.so)
==16220== by 0x355386B61A: fflush (in /usr/lib64/libc-2.15.so)
==16220== by 0x3D2C1101E9: ??? (in /usr/lib64/nvidia/libnvidia-glcore.so.304.64)
==16220== by 0x9846A19C: ???
==16220== Address 0x5b6d018 is not stack’d, malloc’d or (recently) free’d
==16220== HEAP SUMMARY:
==16220== in use at exit: 159,520 bytes in 631 blocks
==16220== total heap usage: 8,170 allocs, 7,540 frees, 7,848,204 bytes allocated
==16220== LEAK SUMMARY:
==16220== definitely lost: 60 bytes in 6 blocks
==16220== indirectly lost: 0 bytes in 0 blocks
==16220== possibly lost: 0 bytes in 0 blocks
==16220== still reachable: 159,460 bytes in 625 blocks
==16220== suppressed: 0 bytes in 0 blocks
==16220== Rerun with --leak-check=full to see details of leaked memory
==16220== For counts of detected and suppressed errors, rerun with: -v
==16220== Use --track-origins=yes to see where uninitialised values come from
==16220== ERROR SUMMARY: 5 errors from 2 contexts (suppressed: 7 from 3)
If I run the game I’m working on with valgrind it seems to work, perhaps hinting the problem involves relying on an uninitialized value.

About my system:
I’m running Fedora 17 x86-64
I have a GeForce FTS 360M and am using the nvidia drivers from RPMFusion, version 304.64
I’m currently attempting to get this to work with the SDL2 snapshot from December 14 (http://www.libsdl.org/tmp/SDL-2.0.0-6754.tar.gz), though I’ve tried with several other versions and it does not appear to make a difference.

So, I’m not sure where the problem is, but I could really use some help figuring it out. I’m on winter break and I’d love to get back to work on my game. Please let me know if there’s any information missing which could be useful.

Update: I rewrote my game to use SFML and everything works perfectly now. Not sure what was wrong, but SFML seems like a good fit for me so I think I’ll stick with it.

I guess this means there’s nothing wrong with my drivers. If anyone wants to try and figure out what’s wrong I’m certainly willing to help, but I won’t be looking into this any further alone.