Platform quirks - darwin

[Rick Robino]

> On Mon, Sep 01, 2003 at 03:39:23PM +0200, Christian Hopp wrote:
> Hi!
> 
> * I have started a PLATFORMS file describing the quirks of our
>   different supported platforms.  So far I have included GNU/Linux
>   (glibc/uClibc/dietlibc) and Solaris (gcc/Forte).

Since this is platform testing week and Christian brought up quirks
I thought I'd return to the malloc error that the mac build brings
up when checking (remote) status.  It can be coerced away and other
platforms won't be bothered by it, but I'm still not sure that there
is a real bug that this fixes - you be the judge:

The error:
time ./monit status
The monit daemon uptime: 13m
*** malloc[3831]: Deallocation of a pointer not malloced: 0x19ea98;
This could be a double free(), or free() called with the middle of
an allocated block; Try setting environment variable MallocHelp to
see tools to help debug
Process 'apache' is running with pid [448]
        Uptime: 2h 24m

                real    0m5.03s
                user    0m0.01s
                sys     0m0.01s


The backtrace:
(gdb) n
92          remote_status(s);
(gdb) n

Breakpoint 1, 0x90001044 in fprintf ()
(gdb) n
Single stepping until exit from function fprintf,
which has no line number information.
*** malloc[3840]: Deallocation of a pointer not malloced: 0x15ea98;
This could be a double free(), or free() called with the middle of
an allocated block; Try setting environment variable MallocHelp to
see tools to help debug
0x90085510 in recycle_host ()
(gdb) bt
#0  0x90085510 in recycle_host ()
#1  0x90036670 in gethostbyname ()
#2  0x00007c7c in create_socket (hostname=0xe2 <Address 0xe2 out of bounds>, 
port=1443, protocol=1, timeout=5) at net.c:248
#3  0x00008ad4 in socket_new (host=0x21a38 "localhost", port=1443, type=226, 
use_ssl=26378) at socket.c:100
#4  0x0000be98 in remote_status (s=0x15dad0) at status.c:250
#5  0x0000b8a0 in status () at status.c:92
#6  0x000071a8 in do_action (args=0xe2) at monitor.c:466
#7  0x00006ab8 in main (argc=2, argv=0x0) at monitor.c:116
#8  0x00001c60 in _start (argc=2, argv=0xbffffb1c, envp=0xbffffb28) at 
/SourceCache/Csu/Csu-45/crt.c:267
#9  0x00001ae0 in start ()


The fix in human-diff format:
change line 100, socket.c 
from
        if((s= create_socket(host, port, proto, NET_TIMEOUT)) != -1)
to
        if((s= create_socket((char *) &host, port, proto, NET_TIMEOUT)) != -1)


Thoughts:  ignore that recycle_host function, its a darwin thing
for their threaded resolver;  line #2 of the backtrace shows a null
value being handed to create_socket.  "hostname" at that point,
IIUC, is either Run.bind_addr or the string constant "localhost" ala'
(a : a ? b).  Those conditional parameters seemed to want an address
instead of a string, so neither the null or localhost value worked...
er... right away, as you can see status hangs for a long time but
finally does print.  The hang is eliminated altogether with the
change but it doesn't handle that localhost fallback value.

This is where I get confused with Process_T and Socket_T, but what
I really don't understand is why building the same kit on OpenBSD
3.3 without changing _anything_ works just fine, no complaints from
the pro-police compiler/linker (even with -pedantic ;-). 

Jan-Henrik asked for this backtrace months ago and then I thought
that by the time 4.0 was released that the bug would be worked out
if it was in monit, plus Rory was on it, otherwise it was probably
an Apple thing.  I can't tell which one it is right now but this
and the ssl bits issue are the only real quirks with the (admittedly
not as important as others) Darwin port.

In other news - seems like someone yesterday closed a printf statement
twice in monitor.c, line 788 in monitor.c (help()).

-- 
Rick Robino                                          
http://wavedivision.com/~rrobino/