tags 334351 + patch pending
thanks
I believe the attached patch solve the issue, but dropping the use of
NGROUPS_MAX, and instead count the number of groups before allocating
the memory needed from the heap.
Please test it and let me know if it solve your problem. Unless you
tell me it failed t
[Petter Reinholdtsen]
> Can you try to apply this diff, to get the size of the memory
> alloctaion printed, and run the program again:
Doh. No need. I see from the backtrace, that the number is very
large (268517376).
Hm, could this be a signed/unsigned issue? Try to apply this patch
and see i
The problem seem to trigger in this code in netplan.c function main().
'==>' marks line 269.
fd_set rd, wr, ex; /* returned fd masks from select */
[...]
nclients = sizeof(fd_set)*8; /* max # of clients */
==> client_list = allocate(nclient
Petter Reinholdtsen <[EMAIL PROTECTED]> writes:
> [Dan Griswold]
>> Will do!
>
> Hm, the problem seem to happen in the forked off child, and not in the
> parent process. Try running the same using netplan -f, to avoid the
> fork.
>
> To test in gdb, do this:
>
> gdb src/netplan
> break exit
>
[Dan Griswold]
> Will do!
Hm, the problem seem to happen in the forked off child, and not in the
parent process. Try running the same using netplan -f, to avoid the
fork.
To test in gdb, do this:
gdb src/netplan
break exit
run -f
bt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with
Petter Reinholdtsen <[EMAIL PROTECTED]> writes:
> [Dan Griswold]
>>> Can you try with ltrace?
>>
>> Yields nothing obviously of value.
>
> Well, please send the last 50 lines anyway
Will do!
cantor:/usr/src/plan-1.9(root)# ltrace netplan
__libc_start_main(0x804bfb0, 1, 0xb914, 0x804deb0, 0x
[Dan Griswold]
>> Can you try with ltrace?
>
> Yields nothing obviously of value.
Well, please send the last 50 lines anyway, to let me know what is
going on when it fails. And send the last 50 strace lines as well,
though I do not expect them to tell me much.
> So, I guess I need to gpg --impo
Petter Reinholdtsen <[EMAIL PROTECTED]> writes:
> Can you try to verify this by installing the old binary package and
> see if it get rid of the problem?
>
> ftp://ftp.debian.org/debian/pool/main/p/plan/netplan_1.9-2_i386.deb>
Verified. 1.9-2 runs, and I can access my served calendars from plan.
[Dan Griswold]
> That's what I thought when I looked in the changelog. I upgrade very
> frequently, so my replaced version must be the immediately previous
> one, 1.9-2.
Can you try to verify this by installing the old binary package and
see if it get rid of the problem?
ftp://ftp.debian.org/debi
Petter Reinholdtsen <[EMAIL PROTECTED]> writes:
> [Dan Griswold]
>> With the new upgrade, the netplan daemon ate up all the memory on the
>> system and caused the xserver and its associated tty to fail. This
>> required a reboot.
>
> Hm. I'm not aware of any changes which could give this result.
[Dan Griswold]
> With the new upgrade, the netplan daemon ate up all the memory on the
> system and caused the xserver and its associated tty to fail. This
> required a reboot.
Hm. I'm not aware of any changes which could give this result. What
was the version number you used before this problem
Package: netplan
Version: 1.9-3
Severity: grave
With the new upgrade, the netplan daemon ate up all the memory on the
system and caused the xserver and its associated tty to fail. This
required a reboot.
Going to plan B, I tried apt-get source and compiling my own. It now
yields this error messag
12 matches
Mail list logo
