Reproduced RHEL-6.6-20140926.0, with autofs-5.0.5-109.el6. Also be reproduced on ppc64, not sure be able to reproduced on s390x.

The stack dump like below:

#0  0x00007f304ce74635 in __strstr_sse42 () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.149.el6.x86_64 libgcc-4.4.7-11.el6.x86_64 libgssglue-0.1-11.el6.x86_64 libtirpc-0.2.1-10.el6.x86_64 libxml2-2.7.6-14.el6_5.2.x86_64 zlib-1.2.3-29.el6.x86_64
(gdb) bt
#0  0x00007f304ce74635 in __strstr_sse42 () from /lib64/libc.so.6
#1  0x00007f304bad0d13 in parse_mount (ap=0x7f305056ecf0, name=0x7f304e30f950 "b1d", name_len=21, mapent=<value optimized out>, context=0x7f30040009b0) at parse_sun.c:1404
#2  0x00007f304aa68149 in lookup_mount (ap=0x7f305056ecf0, name=<value optimized out>, name_len=<value optimized out>, context=0x7f3004000930) at lookup_file.c:1241
#3  0x00007f304e36316d in lookup_name_file_source_instance (ap=0x7f305056ecf0, map=0x7f305056eeb0, name=0x7f304e30fe50 "b1d", name_len=3) at lookup.c:909
#4  0x00007f304e363456 in lookup_nss_mount (ap=0x7f305056ecf0, source=0x0, name=0x7f304e30fe50 "b1d", name_len=3) at lookup.c:1149
#5  0x00007f304e35b758 in do_mount_indirect (arg=<value optimized out>) at indirect.c:768
#6  0x00007f304df149d1 in start_thread () from /lib64/libpthread.so.0
#7  0x00007f304ce329dd in clone () from /lib64/libc.so.6

(In reply to XuWang from comment #1)
> Reproduced RHEL-6.6-20140926.0, with autofs-5.0.5-109.el6. Also be
> reproduced on ppc64, not sure be able to reproduced on s390x.
> 
> The stack dump like below:
> 
> #0  0x00007f304ce74635 in __strstr_sse42 () from /lib64/libc.so.6
> Missing separate debuginfos, use: debuginfo-install
> glibc-2.12-1.149.el6.x86_64 libgcc-4.4.7-11.el6.x86_64
> libgssglue-0.1-11.el6.x86_64 libtirpc-0.2.1-10.el6.x86_64
> libxml2-2.7.6-14.el6_5.2.x86_64 zlib-1.2.3-29.el6.x86_64
> (gdb) bt
> #0  0x00007f304ce74635 in __strstr_sse42 () from /lib64/libc.so.6
> #1  0x00007f304bad0d13 in parse_mount (ap=0x7f305056ecf0,
> name=0x7f304e30f950 "b1d", name_len=21, mapent=<value optimized out>,
> context=0x7f30040009b0) at parse_sun.c:1404
> #2  0x00007f304aa68149 in lookup_mount (ap=0x7f305056ecf0, name=<value
> optimized out>, name_len=<value optimized out>, context=0x7f3004000930) at
> lookup_file.c:1241
> #3  0x00007f304e36316d in lookup_name_file_source_instance
> (ap=0x7f305056ecf0, map=0x7f305056eeb0, name=0x7f304e30fe50 "b1d",
> name_len=3) at lookup.c:909
> #4  0x00007f304e363456 in lookup_nss_mount (ap=0x7f305056ecf0, source=0x0,
> name=0x7f304e30fe50 "b1d", name_len=3) at lookup.c:1149
> #5  0x00007f304e35b758 in do_mount_indirect (arg=<value optimized out>) at
> indirect.c:768
> #6  0x00007f304df149d1 in start_thread () from /lib64/libpthread.so.0
> #7  0x00007f304ce329dd in clone () from /lib64/libc.so.6

I guess you realized this is quite tricky since I haven't commented
on it yet.

Further to our discussion in bug 1161474.

The check here is meant to account for the case where the map
entry has options that make it an internal hosts map so it won't
have a mount location and parse_mapent will return 0. But that
also means myoptions will be undefined and the options we're
looking for won't be in options either since they are per map
entry options. They might be in the map entry being parsed
though. But we can't just check the map entry string either
because the options haven't been isolated so it may match
elsewhere in the string.

Mmmm .....

Ian

Can we run the QA test that exposed this bug again please.

(In reply to Ian Kent from comment #3)
> Can we run the QA test that exposed this bug again please.

Run connectathon with autofs-5.0.5-111.el6 on ppc64, the job link is "
https://beaker.engineering.redhat.com/jobs/880941"
seems good, no core dump for autofs.
I will try more times to issure it.

Run /CoreOS/autofs/connectathon on distro RHEL-6.7-20150304.0, with autofs-5.0.5-112, convers i386, x86_64, s390x, ppc64, no automount segmentfault.
The beaker job is 901698,　901699,　901703,　901711.

Also run regression/bugzillas/stress for on this distro, works fine.

So I change this bug status to be verified.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2015-1344.html