(No need to CC me, I'm on the list)
On Thu, Oct 20, 2005 at 10:31:04PM +0100, Martin Simmons wrote:
> A common reason for this problem is that the padding bytes at the end of the
> sockaddr_in object (called something like sin_zero) are not actually zero.
> Typically this happens when the code fails to initialize them.
>
> Unfortunately, there has been an outbreak of C++ in this code so it is
> impossible to be sure whether it does this :-(
Heh.
> If you can look at the raw bytes passed to bind() in the debugger,
> then you might be able to see what they are.
Ok, I stepped to the point just before the call to bind, and printed
what I *think* is the relevant portion:
(gdb) print/x *(p->saddr4)
$3 = {sin_len = 0x10, sin_family = 0x2, sin_port = 0x238e, sin_addr = {
s_addr = 0x7f000001}, sin_zero = {0x55, 0x55, 0x55, 0x55, 0x55, 0x55,
0x55, 0x55}}
And yes, you're correct, the extra stuff is not zero. Gotcha, you little
bugger.
So: in src/lib/address_conf.c, for both constructors:
IPADDR::IPADDR(const IPADDR &src) : type(src.type)
IPADDR::IPADDR(int af) : type(R_EMPTY)
add:
memset(&saddrbuf, 0, sizeof(saddrbuf));
before doing anything else to/with saddrbuf.
This fixes the problem: I can now bind to arbitrary addresses (well, at
least the ones that exist on the box).
Martin, you're my new hero. Kern, did you catch this? Should I send
the patch someplace specific? Actually, I prefer that someone who
actually understands C++ confirm that this is patch is both correct and
sufficient...
Thanks,
Steve,
--
"Outlook not so good." That magic 8-ball knows everything! I'll ask
about Exchange Server next.
-- (Stolen from the net)
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Bacula-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-users