[solved] groff segmentation fault in CGI

N_BaH · 2021-11-10 05:59:50

hi,

I'm writing a simple man2html CGI script :

#!/bin/bash

printf 'Content-type: text/html\n\n'
echo '<!doctype html>'
exec 2>&1
set -x
zcat /usr/share/man/man1/man.1.gz | groff -man -Thtml -
set +x

this script works well on Debian.
here's what I get on Archlinux:

+ zcat /usr/share/man/man1/man.1.gz
+ groff -man -Thtml - /srv/http/cgi-bin/test: line 7: 94180 Done zcat /usr/share/man/man1/man.1.gz 94181 Segmentation fault (core dumped) | groff -man -Thtml -
+ set +x

I have other CGI scripts that work as intended.

Last edited by N_BaH (2021-11-18 18:00:13)

seth · 2021-11-10 07:07:13

So…? Maybe look at the coredump?
https://wiki.archlinux.org/title/Core_d … _core_dump

N_BaH · 2021-11-10 07:23:47

here's what I get from gdb backtrace

Reading symbols from /usr/bin/groff...
(No debugging symbols found in /usr/bin/groff)
[New LWP 143950]
Core was generated by `groff -man -Thtml'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007f14035b34c7 in __strchr_sse2 () from /usr/lib/libc.so.6
(gdb) bt
#0  0x00007f14035b34c7 in __strchr_sse2 () from /usr/lib/libc.so.6
#1  0x00005642eaf6aa7a in ?? ()
#2  0x00005642eaf6ad0e in ?? ()
#3  0x00005642eaf6af35 in ?? ()
#4  0x00005642eaf621b1 in ?? ()
#5  0x00007f140353cb25 in __libc_start_main () from /usr/lib/libc.so.6
#6  0x00005642eaf6293e in ?? ()
(gdb)

but it doesn't tell me much.
do you need more?

btw, there's one big difference between Debian and Arch installations : the former uses apache2, the latter uses lighttpd.

seth · 2021-11-10 07:55:39

It crashes in the sse2 implementation of strchr
Can you reproduce this interactively

zcat /usr/share/man/man1/man.1.gz | groff -man -Thtml -
zcat /usr/share/man/man1/man.1.gz > /tmp/man.1; groff -man -Thtml /tmp/man.1

And on a hunch

localectl
locale
locale -a

N_BaH · 2021-11-10 15:09:29

interactively, `zcat | groff' work fine, as using an intermediate file.

here's the result of additional commands :

$ localectl
   System Locale: LANG=fr_FR.UTF-8
       VC Keymap: fr-latin9
      X11 Layout: n/a

$ locale
LANG=fr_FR.UTF-8
LC_CTYPE="fr_FR.UTF-8"
LC_NUMERIC="fr_FR.UTF-8"
LC_TIME="fr_FR.UTF-8"
LC_COLLATE="fr_FR.UTF-8"
LC_MONETARY="fr_FR.UTF-8"
LC_MESSAGES="fr_FR.UTF-8"
LC_PAPER="fr_FR.UTF-8"
LC_NAME="fr_FR.UTF-8"
LC_ADDRESS="fr_FR.UTF-8"
LC_TELEPHONE="fr_FR.UTF-8"
LC_MEASUREMENT="fr_FR.UTF-8"
LC_IDENTIFICATION="fr_FR.UTF-8"
LC_ALL=

$ locale -a
C
fr_FR.utf8
nl_NL.utf8
POSIX
$

seth · 2021-11-10 15:18:03

Locale looks fine - does running your script interactively crash?
What if you don't redirect stderr into stdout?

N_BaH · 2021-11-10 16:22:03

in a terminal, the script works perfectly.
I redirected stderr because nothing appeared in browser.
if I don't, I have no man page, and no error message in browser.

seth · 2021-11-10 16:36:59

Can you

zcat /usr/share/man/man3/strchr.3.gz | groff -man -Thtml - # shorter file …
zcat /usr/share/man/man3/strchr.3.gz | groff -man -Tascii - # … and less effort

N_BaH · 2021-11-10 16:50:19

they both cause segmentation fault.

Last edited by N_BaH (2021-11-10 17:01:31)

seth · 2021-11-10 17:12:16

Do you use the cgi or the fastcgi module?
System is fully updated? No partital updates?

N_BaH · 2021-11-10 18:02:08

cgi module is cgi (no fastcgi).
system is fully updated; non partial update.

Last edited by N_BaH (2021-11-10 22:23:13)

N_BaH · 2021-11-10 22:23:20

I installed apache2 using simple cgi_mod on an lxc machine, and finally made the script work in the container.
so, the problem seems to come from lighttpd...

seth · 2021-11-11 07:55:24

finally made the script work in the container

?
Is lighttpd also a container installation??
Because in that case it is *faaaaaar* more likely the container and the contained glibc…

N_BaH · 2021-11-11 13:29:14

no, lighttpd is on hardware.

N_BaH · 2021-11-12 04:19:07

as it seems to be a lighttpd issue, should I close this thread and open a new one under "Networking, Server and Protection" section?

seth · 2021-11-12 07:35:12

It's not network related but programming & scripting is false as well, since it's not about your script either.

If you suffix the script .sh and assign that to /usr/bin/bash, does it still segfault?
https://wiki.archlinux.org/title/Lighttpd#CGI

N_BaH · 2021-11-12 14:12:23

assigning .sh to /usr/bin/bash doesn't change a thing : it still "segfaults".

here's /etc/lighttpd/lighttpd.conf :

# See /usr/share/doc/lighttpd
# and http://redmine.lighttpd.net/projects/lighttpd/wiki/Docs:ConfigurationOptions

server.port		= 80
server.username		= "http"
server.groupname	= "http"
server.document-root	= "/srv/http"
server.errorlog		= "/var/log/lighttpd/error.log"
dir-listing.activate	= "enable"
index-file.names	= ( "index.html", "cgi-bin/accueil" )
mimetype.assign		= (
				".html" => "text/html",
				".txt" => "text/plain",
				".css" => "text/css",
				".js" => "application/x-javascript",
				".jpg" => "image/jpeg",
				".jpeg" => "image/jpeg",
				".gif" => "image/gif",
				".png" => "image/png",
				"" => "application/octet-stream"
			)
server.modules += ( "mod_userdir" )
userdir.path = "public_html"

server.modules += ( "mod_cgi" )
cgi.assign = (
	".sh" => "/usr/bin/bash" #this doesn't change wrong behaviour
)
#$HTTP["url"] =~ "^(/~[^/]+)?/cgi-bin/" { #this is default config found on internet; it works with other CGI shell scripts.
#	cgi.assign = ("" => "")
#}

# PDF view files instead of downloading
#https://azgtech.wordpress.com/2011/01/26/force-download-pdf-using-lighttpd/
#https://stackoverflow.com/questions/6293893/how-do-i-force-files-to-open-in-the-browser-instead-of-downloading-pdf
server.modules += ( "mod_setenv" )
$HTTP["url"] =~ "(.*)\.pdf" {
	mimetype.assign = (".pdf" =>"application/pdf")
	setenv.add-response-header = ( "Content-Disposition" => "inline" )
}
# Redirection
$HTTP["host"] == "machine_name" {
	$HTTP["url"] =~ "^/$" {
		url.redirect = ( "" => "/cgi-bin/home" )
		url.rediect-code = 302
	}
}

Last edited by N_BaH (2021-11-12 14:13:20)

N_BaH · 2021-11-18 18:02:46

silly me !
groff uses so many "sub programs", I remember that I tested PATH variable, though.
I probably didn't refresh browser's cache.

so, I set PATH to /usr/local/sbin:/usr/local/bin:/usr/bin, and I don't have segfault any more.

thnak you for your time, and sorry for such a simple error.

Arch Linux

#1 2021-11-10 05:59:50

[solved] groff segmentation fault in CGI

#2 2021-11-10 07:07:13

Re: [solved] groff segmentation fault in CGI

#3 2021-11-10 07:23:47

Re: [solved] groff segmentation fault in CGI

#4 2021-11-10 07:55:39

Re: [solved] groff segmentation fault in CGI

#5 2021-11-10 15:09:29

Re: [solved] groff segmentation fault in CGI

#6 2021-11-10 15:18:03

Re: [solved] groff segmentation fault in CGI

#7 2021-11-10 16:22:03

Re: [solved] groff segmentation fault in CGI

#8 2021-11-10 16:36:59

Re: [solved] groff segmentation fault in CGI

#9 2021-11-10 16:50:19

Re: [solved] groff segmentation fault in CGI

#10 2021-11-10 17:12:16

Re: [solved] groff segmentation fault in CGI

#11 2021-11-10 18:02:08

Re: [solved] groff segmentation fault in CGI

#12 2021-11-10 22:23:20

Re: [solved] groff segmentation fault in CGI

#13 2021-11-11 07:55:24

Re: [solved] groff segmentation fault in CGI

#14 2021-11-11 13:29:14

Re: [solved] groff segmentation fault in CGI

#15 2021-11-12 04:19:07

Re: [solved] groff segmentation fault in CGI

#16 2021-11-12 07:35:12

Re: [solved] groff segmentation fault in CGI

#17 2021-11-12 14:12:23

Re: [solved] groff segmentation fault in CGI

#18 2021-11-18 18:02:46

Re: [solved] groff segmentation fault in CGI

Board footer