Here's the stack backtrace:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208183104 (LWP 5456)]
0x00d7c055 in globus_i_gss_assist_gridmap_find_local_user (local_user=0xa0e3dd0
"vwelch", gline=0xbfe7e338) at gridmap.c:726
726            for(useridp = gline_tmp->user_ids; 
(gdb) bt
#0  0x00d7c055 in globus_i_gss_assist_gridmap_find_local_user
(local_user=0xa0e3dd0 "vwelch", gline=0xbfe7e338) at gridmap.c:726
#1  0x00d7b920 in globus_gss_assist_map_local_user (local_user=0xa0e3dd0
"vwelch", globusidp=0xbfe7e36c) at gridmap.c:419

The globus_gss_assist_map_local_user() function calls fgets() with a 1024
character buffer but does not check whether the line has been truncated by
looking for '\n' at the end of the string. So, lines longer than 1022
characters (1024-2 for the '\n' and '\0' terminating characters) will be split
and processed as multiple lines, causing parse errors that result in
segmentation faults (see Bug 6429). This was also noted in Bug 4180. This bug
was crashing NCSA's production myproxy-server today until we removed the
offending grid-mapfile line from NCSA's grid-mapfiles.

I see 3 calls to fgets() in gridmap.c that behave this way.

At minimum, these functions should throw an error on too-long lines and/or
discard them (completely) and keep processing, but ideally they'd use a
dynamically-sized buffer to handle lines of any length in the grid-mapfile.