runit/svlogd: segfault, uninitialized strallocs?

[mcz]

On one of my PCs (runit-2.1.2, voidlinux, raspberry pi) this happens
when the number of logdir arguments is large enough:

---8<---
# strace svlogd -ttt /var/log/socklog/*
[...]
open("/var/log/socklog/daemon", O_RDONLY|O_NONBLOCK|O_LARGEFILE) = 4
fcntl64(4, F_SETFD, FD_CLOEXEC) = 0
fchdir(4)   = 0
open("lock", O_WRONLY|O_CREAT|O_APPEND|O_NONBLOCK|O_LARGEFILE, 0600) = 5
flock(5, LOCK_EX|LOCK_NB)   = 0
fcntl64(5, F_SETFD, FD_CLOEXEC) = 0
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x68732067} ---
+++ killed by SIGSEGV +++
Segmentation fault
#
---8<---

The dir structures (which are allocated at svlogd.c:706) don't seem to
be zeroed at all when alloc falls back to malloc (alloc.c:21). Then,
uninitialized dir[0].prefix gets passed to stralloc_copys
(svlogd.c:435) and svlogd receives SIGSEGV at stralloc_opyb.c:11.

Is this a bug or am I missing something?

-- 
mcz

Re: Compatibilities between runit and s6 (re: Incompatibilities between runit and s6?)

[Jonathan de Boyne Pollard]

Jonathan de Boyne Pollard:

The |service-manager| manual page from version 1.37 or later of the 
nosh toolset contains  a full breakdown of the control/status API in a 
|supervise/| directory, including the daemontools-encore extensions 
and the nosh service-manager's own extensions.  I am hoping to get 
version 1.37 released within the next week.  In the meantime, I have 
pushed the new manual page to the on-line copy of the /nosh Guide/ 
.  You can find the HTML-form 
manual page for |service-manager| hyperlinked from several pages in 
the /Guide/, including the _new Interfaces_ page.



Charlie Brady:

Do you know whether anyone has documented how to build on a non-Debian 
linux? An rpm spec file would be ideal, but just simple non-Debian 
centric build instructions would be better than nothing.


Yes.  I have.  The slashpackage-style build instructions, which are of 
course /not/ Debian-specific nor even /Linux-/specific, are actually 
right there on the source package WWW page.


The only thing that is Debian-specific is the step that gets one from a 
/built/ slashpackage-style package to Debian binary packages.  This is 
in the supplied |package/debian/rules| command.  But even that is not 
actually Debian-specific, as there is a similar |package/bsd/rules| 
command that does the same thing on the BSDs.


Thomas Caravia constructed the Archnosh PKGBUILD the same way. It does 
the slashpackage-style build, then takes the built slashpackage-style 
package and parcels it out into a set of Arch binary packages, with a 
light dusting of patches to a handful of service bundles.  It even 
mostly re-uses the Debian maintenance scripts.


(On that note, Thomas: You may enjoy the start that I have made in 1.37 
to a _Packages and Ports_ chapter in the /nosh Guide/.  Yes, I currenly 
plan for the |.p|/|.func| system to get at least a short mention.)


I was only expecting you to read the manual for doco on the common 
control/status API that you were interested in, not build the software.  (-:

Re: Compatibilities between runit and s6 (re: Incompatibilities between runit and s6?)

[Jonathan de Boyne Pollard]

Charlie Brady:

There is a certain level of compatibility between daemontools and 
runit, and I presume the same exists for s6. The devil is in the detils.


The |service-manager| manual page from version 1.37 or later of the nosh 
toolset contains  a full breakdown of the control/status API in a 
|supervise/| directory, including the daemontools-encore extensions and 
the nosh service-manager's own extensions.  I am hoping to get version 
1.37 released within the next week.  In the meantime, I have pushed the 
new manual page to the on-line copy of the /nosh Guide/ 
.  You can find the HTML-form manual 
page for |service-manager| hyperlinked from several pages in the 
/Guide/, including the _new Interfaces_ page.