Re: monit 4.8 segfaults on Redhat EL4

[Rory Toma]

Jan-Henrik Haukeland wrote:
> On 4. mai. 2006, at 19.16, Mike Jackson wrote:
>
> > Program received signal SIGSEGV, Segmentation fault.
> > [Switching to Thread 182894082848 (LWP 30022)]
> > 0x0000003106b6fd00 in strlen () from /lib64/tls/libc.so.6
> > (gdb) backtrace
> > #0  0x0000003106b6fd00 in strlen () from /lib64/tls/libc.so.6
> > #1  0x0000003106b428cc in vfprintf () from /lib64/tls/libc.so.6
> > #2  0x0000003106bc1e55 in vsyslog () from /lib64/tls/libc.so.6
> > #3  0x000000000040910c in log_log (priority=6, s=0x42af60 "Starting 
> > %s daemon with http interface at [%s:%d]\n", ap=0x7fbffff6c0)
> >    at log.c:374
> > #4  0x0000000000409358 in LogInfo (s=Variable "s" is not available.
> > ) at log.c:247
> > #5  0x000000000040b332 in main (argc=Variable "argc" is not available.
> > ) at monitor.c:460
>
>
> Thank you very much for this report Mike. This trace does not make any 
> sense to me though. It shows 's' with an address and then go on to say 
> that s is not available. Also not having argc available for main() is 
> suspicious to say the least. Does this segfault happens all the time 
> or only sporadic? Do you use any special C libraries that you are 
> aware of? I cannot reproduce this segfault on any Linux (SMP) machines 
> I have so I wonder if you can run gdb on monit yourself and set a 
> breakpoint in 'log_log' and step trough to see if anything strange is 
> going on or maybe where the problem occurs. Use e.g.
>
> $ gdb ./monit
> GNU gdb Red Hat Linux (6.3.0.0-1.122rh)
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and 
> you are
> welcome to change it and/or distribute copies of it under certain 
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for 
> details.
> This GDB was configured as "i386-redhat-linux-gnu"...Using host 
> libthread_db library "/lib/libthread_db.so.1".
>
> (gdb) break log_log
> Breakpoint 1 at 0x804ff72: file log.c, line 362.
> (gdb) run -Iv
> Starting program: /home/hauk/utv/monit/monit -Iv
> Reading symbols from shared object read from target memory...done.
> Loaded system supplied DSO at 0x982000
> [Thread debugging using libthread_db enabled]
> [New Thread -1208101200 (LWP 2605)]
> [Switching to Thread -1208101200 (LWP 2605)]
>
> Breakpoint 1, log_log (priority=7,
>     s=0x8080378 "%s: Debug: Adding credentials for user '%s'.\n",
>     ap=0xbfeed144 "\\??H\230\233\tԽ\006\b\001") at log.c:362
> 362       ASSERT(s);
> (gdb) n
> ...
>
> > I also ran it through strace, which produces volumes of output, but I 
> > won't send that unless someone needs it.
>
> You can send the strace dump to our contact address (monitgroup at 
> tildeslash.com), but try the above first.
>
> --
> Jan-Henrik Haukeland
> Mobil +47 97141255
>
>
>
> --
> To unsubscribe:
> http://lists.nongnu.org/mailman/listinfo/monit-general
I just checked in what I think to be the fix.

In a nutshell, when you pass a va list, on 64 bit amd and PPC platforms, 
you must use va_copy to initialize the list, and then copy the original 
list to the copy, as in:

#ifdef HAVE_VA_COPY
va_list ap_copy;
va_copy(ap_copy, ap);
<use ap_copy in function here>
va_end(ap_copy);
#endif

It has something to do with the chip arch. In any case, please use the 
above when using va_lists.

I can't test it, as I no longer have my 64 bit machine.