From: Zdenek Kabelac <zkabelac@redhat.com>
To: lvm-devel@redhat.com
Subject: [PATCH] dmeventd coredump fix
Date: Fri, 15 Jan 2010 13:55:48 +0100 [thread overview]
Message-ID: <4B5065D4.10108@redhat.com> (raw)
In-Reply-To: <4B4EDBDF.7070509@redhat.com>
Dne 14.1.2010 09:54, Zdenek Kabelac napsal(a):
> Hi
>
> I've noticed that on my test machine dmeventd generates quite often weird
> coredumps with somewhat strange backtraces.
>
> Thus I've searched for the reason and with valgrind trace I've noticed
> problem with struct cmdline_context _cmdline
>
> Thread 2:
> Conditional jump or move depends on uninitialised value(s)
> at 0x4C9B826: free (vg_replace_malloc.c:325)
> by 0x751C86F: lvm_fin (lvmcmdline.c:1213)
> by 0x7537ACC: lvm2_exit (lvmcmdlib.c:116)
> by 0x7365BEE: unregister_device (dmeventd_mirror.c:316)
> by 0x804AAFE: _monitor_unregister (dmeventd.c:664)
> by 0x804B853: _monitor_thread (dmeventd.c:805)
> by 0x4CBC584: start_thread (pthread_create.c:300)
> by 0x6EA426D: clone (clone.S:130)
>
> Invalid free() / delete / delete[]
> at 0x4C9B866: free (vg_replace_malloc.c:325)
> by 0x751C86F: lvm_fin (lvmcmdline.c:1213)
> by 0x7537ACC: lvm2_exit (lvmcmdlib.c:116)
> by 0x7365BEE: unregister_device (dmeventd_mirror.c:316)
> by 0x804AAFE: _monitor_unregister (dmeventd.c:664)
> by 0x804B853: _monitor_thread (dmeventd.c:805)
> by 0x4CBC584: start_thread (pthread_create.c:300)
> by 0x6EA426D: clone (clone.S:130)
> Address 0x51 is not stack'd, malloc'd or (recently) free'd
>
> Crash seems to appear when mirror device is reregistered during our test suit.
> Not really sure if it's related to some other reported problems.
>
> Basically we need to clear commands_size & num_commands and
> it doesn't matter if it is in init or finish -
>
> I'm proposing this oneline patch:
>
> --- tools/lvmcmdline.c 11 Jan 2010 19:19:17 -0000 1.111
> +++ tools/lvmcmdline.c 14 Jan 2010 08:33:50 -0000
> -1192,6 +1192,7 @@ struct cmd_context *init_lvm(void)
> {
> struct cmd_context *cmd;
>
> + memset(&_cmdline, 0, sizeof(_cmdline));
> _cmdline.the_args = &_the_args[0];
>
> if (!(cmd = create_toolcontext(0, NULL)))
>
Ok - patch above has some problems with order of calling lvm2_init() calls;
So here comes simpler version which only clears structure elements right after
they are being released:
--- tools/lvmcmdline.c 11 Jan 2010 19:19:17 -0000 1.111
+++ tools/lvmcmdline.c 15 Jan 2010 12:51:58 -0000
@@ -1213,6 +1213,10 @@ static void _fin_commands(void)
dm_free(_cmdline.commands[i].valid_args);
dm_free(_cmdline.commands);
+
+ _cmdline.commands = NULL;
+ _cmdline.num_commands = 0;
+ _cmdline.commands_size = 0;
}
void lvm_fin(struct cmd_context *cmd)
Zdenek
next parent reply other threads:[~2010-01-15 12:55 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4B4EDBDF.7070509@redhat.com>
2010-01-15 12:55 ` Zdenek Kabelac [this message]
2010-01-20 12:53 ` [PATCH] dmeventd coredump fix Zdenek Kabelac
2010-01-21 13:34 ` Milan Broz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4B5065D4.10108@redhat.com \
--to=zkabelac@redhat.com \
--cc=lvm-devel@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.