Re: problem of memory leak in re-direction (shell/ash.c: expredir)
On Mon, Dec 15, 2014 at 02:55:41PM +0800, shengyong wrote: > hi, all > I meet the memory leak problem when use re-direction in a reading-loop, like: > > while true > do > while true > do > break > done < /dev/null > done > > There is some discussion on this issue: > * http://lists.busybox.net/pipermail/busybox/2012-December/078738.html > * https://bugs.busybox.net/show_bug.cgi?id=5822 > > But it is still not fixed in the later versions? AFAIK it is not fixed. As I stated in the bug report you linked, a proper fix would require dropping the (semantically invalid) use of the current stack-like allocation strategy and replacing it with some sort of reference-tree structure that allows freeing of allocations other than the most-recent. The easiest way I can see to do this would be writing an allocator similar to talloc or adapting talloc itself if the license and code size are acceptable. But in any case I think it's a non-trivial task and nobody's volunteered to do it. Rich ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
problem of memory leak in re-direction (shell/ash.c: expredir)
hi, all I meet the memory leak problem when use re-direction in a reading-loop, like: while true do while true do break done < /dev/null done There is some discussion on this issue: * http://lists.busybox.net/pipermail/busybox/2012-December/078738.html * https://bugs.busybox.net/show_bug.cgi?id=5822 But it is still not fixed in the later versions? thanks & regards ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [RFC][PATCHv2] new applets: i2c-tools
Hello, 2014-12-13 1:31 GMT+01:00 Isaac Dunham : > On Fri, Dec 12, 2014 at 12:09:55AM +0100, Xabier Oneca -- xOneca wrote: >> If you mistype 'i2cbus' parameter in the command line, you will have >> both a warning and an error opening two devices, which can be >> misleading. >> >> Why would you even try to open the old-style device in a new kernel, >> or a new-style dev in an old one? I think this can be avoided with the >> usual '#if LINUX_VERSION ...', be it with preprocessor instructions, >> or with a plain 'if ... else' statement. > > This is the wrong way, IMHO. > It means that you *cannot* compile busybox with i2ctools that work on > pre-2.6.14(?) kernels, unless you build it using 2.6.14 or older headers; > and in that case, you must recompile busybox if you upgrade the kernel. > It would be tolerable if it were right at the 2.4/2.6 cutoff, but it > isn't. > > Also, someone could configure a newer kernel to use the same layout for > /dev as an older kernel in at least two ways: > -if they use a static /dev > -if they configure the hotplug helper to use the old layout (for > example, for backwards compatability). > In mdev, that might look like this: > i2c-([0-9]*)root:i2c0660=i2c/%1 That's reasonable... Didn't think on this. > I would support checking both paths. Makes sense. Indeed, if that's the way i2c-tools works... Convinced! :) Cheers, Xabier Oneca_,,_ ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
