Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: uninitialised value & valgrind |
| Date | 2012-06-26 15:42 -0400 |
| Organization | A noiseless patient Spider |
| Message-ID | <4FEA108F.2060103@verizon.net> (permalink) |
| References | <jscobj$amb$1@speranza.aioe.org> <4FE9F706.6060301@verizon.net> <jsctpa$p6o$1@speranza.aioe.org> |
On 06/26/2012 02:07 PM, Mark wrote:
> "James Kuyper" <jameskuyper@verizon.net> wrote in message
> news:4FE9F706.6060301@verizon.net...
> [skip]
>> The messages you're getting from valgrind suggest that something is
>> attempting to access the non-existent message data inside of __write().
>> You don't show us how msg_len is calculated. However, if it's greater
>> than sizeof(struct vlog_msg_header), that would explain the messages
>> from valgrind.
>>
>> I'd recommend figuring out why msg_len Is greater than that limit - it
>> suggests a serious disconnect between what you think you're doing and
>> what you're actually doing. The most plausible kind of mistake would be
>> failing to set header.vmh_data_len to 0.
>
> #define VLOG_MSG_HDR_SIZE sizeof (struct vlog_msg_header)
> int vlog_client_send_message (struct vlog_msg *msg)
> {
> u_int16_t msg_len = VLOG_MSG_HDR_SIZE + msg->vms_msg_hdr.vmh_data_len;
> ...
> }
>
> and this is how 'header' is initialised:
>
> struct vlog_msg_header header;
> ...
> header.vmh_msg_type = VLOG_MSG_TYPE_CTRL;
> header.vmh_vr_id = 0;
> header.vmh_mod_id = zg->protocol;
> header.vmh_proc_id = pal_get_process_id();
> header.vmh_priority = 0;
> header.vmh_data_len = 0;
> vlog_client_send_message (zg->vlog_clt, (struct vlog_msg *)&header);
> ...
>
> So msg_len should be of valid length.
I'd recommend checking to make sure that msg_len is still <= sizeof
(struct vlog_msg_header) at the point of the call to write(). It might
have changed, and if so, you need to find out why.
Another possibility is that struct vlog_msg_header may have padding
bytes. The fact that there's an s_int8_t member between two u_int32_t
members would generally result in padding on any system where u_int32_t
has a non-trivial alignment requirement. If that's the case, then those
padding bytes would be uninitialized by your code, but the call to
write() would attempt to write them anyway.
If you have the power to change the structure definitions, I recommend
putting the members in decreasing order of size; this will tend to
minimize the number of padding bytes needed. Note: you can safely
convert from a pointer to a struct and a pointer to the first member of
the struct, and vice versa. If any of the code that uses this struct
takes advantage of that fact, you can't move that member.
There's no way to guarantee that a struct has no padding. The only way
to guarantee initialization of the whole struct, including padding
bytes, is to give the struct object static or thread storage duration,
or to use memset() or something equivalent to memset..
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
uninitialised value & valgrind "Mark" <mark_cruzNOTFORSPAM@hotmail.com> - 2012-06-26 12:35 -0400
Re: uninitialised value & valgrind James Kuyper <jameskuyper@verizon.net> - 2012-06-26 13:53 -0400
Re: uninitialised value & valgrind "Mark" <mark_cruzNOTFORSPAM@hotmail.com> - 2012-06-26 14:07 -0400
Re: uninitialised value & valgrind James Kuyper <jameskuyper@verizon.net> - 2012-06-26 15:42 -0400
Re: uninitialised value & valgrind Johann Klammer <klammerj@NOSPAM.a1.net> - 2012-06-27 02:09 +0200
csiph-web