The fix for this bug has been committed.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.

 For Windows:

http://windows.php.net/snapshots/
 
Thank you for the report, and for helping us make PHP better.

Is there any test case to trigger this crash?

NULL dereference isinsets() can only happen if ncols is greater than 0.  ncols is:

1276         register int ncols = (g->ncsets+(CHAR_BIT-1)) / CHAR_BIT;

ncsets is initialized to 0:

 141         g->ncsets = 0;

and only changed in allocset():

1003         register int no = p->g->ncsets++;

Further on in allocset():

1010         if (no >= p->ncsalloc) {        /* need another column of space */
1011                 p->ncsalloc += CHAR_BIT;

...

1020                 if (p->g->setbits == NULL)
1021                         p->g->setbits = (uch *)malloc(nbytes);
1022                 else {
1023                         p->g->setbits = (uch *)realloc((unsigned char *)p->g->setbits,
1024                                                                 nbytes);

ncsalloc is also initialized to 0 and only incremented in allocset().  Hence on the first allocset() call, the code to allocate setbits it reached.  So isinsets() NULL dereference could only happen on failed malloc, and if subsequent SETERROR fails to halt processing as it's meant to.  Is there some code path I'm overlooking?