[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: monit 4.8 segfaults on Redhat EL4

From: Rory Toma
Subject: Re: monit 4.8 segfaults on Redhat EL4
Date: Thu, 04 May 2006 13:33:03 -0700
User-agent: Thunderbird (Macintosh/20060308)

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/
(gdb) backtrace
#0  0x0000003106b6fd00 in strlen () from /lib64/tls/
#1  0x0000003106b428cc in vfprintf () from /lib64/tls/
#2  0x0000003106bc1e55 in vsyslog () from /lib64/tls/
#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 (
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/".

(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, but try the above first.

Jan-Henrik Haukeland
Mobil +47 97141255

To unsubscribe:

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:

va_list ap_copy;
va_copy(ap_copy, ap);
<use ap_copy in function here>

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]