[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Freeipmi-devel] k_g memory error
From: |
Al Chu |
Subject: |
Re: [Freeipmi-devel] k_g memory error |
Date: |
Mon, 07 May 2007 13:43:59 -0700 |
Hey Levi,
I see what you're saying. Right now I only see this issue in
ipmipower/src/ipmipower_prompt.c. Do you see it anywhere else?
Also, looking at format_kg() it seems that:
assert(outsz > IPMI_MAX_K_G_LENGTH*2);
should be
assert(outsz > IPMI_MAX_K_G_LENGTH*2+2);
??
Al
On Mon, 2007-05-07 at 11:51 -0600, Levi Pearson wrote:
> I was reviewing the k_g hex input/output as it exists in the CVS trunk
> now, and I ran across a problem. Fortunately, it should only show
> itself when debugging is enabled. Here's the issue: When printing the
> k_g key in hex, the caller of format_kg must allocate sufficient memory
> to hold it. I believe when I originally wrote format_kg, I told it to
> allocate IPMI_MAX_K_G_LENGTH*2+2, which accounts for the hex
> representation of 20 bytes plus the '0x' prepended to it. It seems to
> have been changed to IPMI_MAX_K_G_LENGTH*2+1, which accounts for the hex
> representation of 20 bytes plus the NULL termination. What it really
> should be, and is in my bmc-config patches where it's really called in a
> non-debug context, is IPMI_MAX_K_G_LENGTH*2+3, which accounts for the
> '0x' and NULL.
>
> Sorry I didn't catch and report this earlier. Maybe a better fix for
> this would be to define a new macro, IPMI_K_G_STRING_REP_LENGTH or
> something similar, that would expand to IPMI_MAX_K_G_LENGTH*2+2, and
> then we would only have to account for the NULL byte with a +1. What do
> you think?
>
> --Levi
>
>
>
>
> _______________________________________________
> Freeipmi-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/freeipmi-devel
>
--
Albert Chu
address@hidden
925-422-5311
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory