On my Ubuntu installation this removes 15k of duplicate strings,
using a temporary index of about 25k.
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
On Fri, Nov 7, 2008 at 13:07, Matthias Schwarzott <zzam@gentoo.org> wrote:
> I managed to let udev-131 segfault at startup.
>
> I configured it like this:
> CFLAGS="-Wall -ggdb" ./configure --prefix=/usr --sysconfdir=/etc --exec-prefix=
>
> Running it in gdb shows it segfaults at udev-rules.c:831
>
> (gdb) run
> Starting program: /tmp/udev-131/udev/udevd
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x0804ea06 in get_key (udev=0x9175008, line=0xafcdc8f0, key=0xafcdc5d8,
> op=0xafcdc5d0, value=0xafcdc5d4)
> at udev-rules.c:831
> 831 dbg(udev, "%s '%s'-'%s'\n", operation_str[*op], *key, *value);
If compiled without optimization, the dbg() macro dereferences variables
which are not available. Convert the string array to a function, which just
returns NULL if compiled without DEBUG.
I'm worried about what will happen with things like
KERNELS=="*" # pointless rule
KERNELS=="doesnt-match" # another pointless rule
Since TK_RULE < TK_M_PARENTS_MAX, we will try to match all three tokens
against parents of the current device. I can't think of a bad case,
but it's not exactly good either.
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
LAST_RULE was broken, and I broke TK_END by making it do the same.
It used a "break" which exited the switch statement, but not the loop!
==2953== Invalid read of size 4
==2953== at 0x4081EE: dump_token (udev-rules.c:859)
==2953== by 0x40BADB: udev_rules_apply_to_event (udev-rules.c:1849)
==2953== by 0x403F17: udev_event_execute_rules (udev-event.c:554)
==2953== by 0x418626: main (test-udev.c:100)
==2953== Address 0x55ab1f8 is 0 bytes after a block of size 80 alloc'd
==2953== at 0x4C23082: realloc (vg_replace_malloc.c:429)
==2953== by 0x40B13B: udev_rules_new (udev-rules.c:1670)
==2953== by 0x418536: main (test-udev.c:84)
...
Signed-off-by: Alan Jenkins <alan-jenkins@tuffmail.co.uk>
On Thu, Oct 30, 2008 at 03:55, Tejun Heo <tj@kernel.org> wrote:
The appropriate default timeout differs depending on the transport and
the type of the attached device, so the above two rules harm more than
help. The affect of the above two rules weren't visible for some
reason but with recent block layer timeout update, they actually work
and cause problems.
Kay Sievers
Karel Zak
Alan Jenkins