Hi Carlo:
On Wed, Feb 23, 2011 at 2:15 AM, Carlo Marcelo Arenas Belon
<care...@sajinet.com.pe> wrote:
> I must be missing something here since I don't see the connection.
>
> The bug (which is IMHO invalid) is reporting that a string gets truncated
> to 32 bytes, which is a current design limit for metrics as defined by
> MAX_G_STRING_SIZE and the fact that a g_val_t union is used to hold the
> values (both defined in gm_value.h).
>
> The "resizable" buffer is not even used in this call, since the buffer
> passed to slurpfile is a static 32 byte array (for the buffer to be
> allocated and dynamically resized it should be a pointer to null), and
> considering that the bug is asking for the os release name, 32 bytes
> should be enough, at least to get a unique identification.
You're right. I failed to mention that in my own code I set
proc_sys_kernel_osrelease to NULL so that the buffer will be resized
dynamically.
> what second pass?
>
> dummy = proc_sys_kernel_osrelease;
> rval.int32 = slurpfile("/proc/sys/kernel/osrelease", &dummy,
> MAX_G_STRING_SIZE);
>
> why would anyone call slurpfile in a loop anyway?, and slurpfile
> doesn't call itself recursively but just reads as much data as it
> can into the buffer provided (second parameter).
Sorry I wasn't clear, I meant the "goto read" loop:
123 read:
124 read_len = read(fd, db, buflen);
125 if (read_len <= 0)
126 {
127 if (errno == EINTR)
128 goto read;
129 err_ret("slurpfile() read() error on file %s", filename);
130 close(fd);
131 return SYNAPSE_FAILURE;
132 }
When I straced the process, the first read() was able to read up to
MAX_G_STRING, however, the second read() returns 0. However, if I
read a regular file (not in /proc filesystem), it was able to read the
rest of the string in the "second" pass just fine.
> and so it should be working as well in this case AFAIK.
I tested under EL5 and EL6 and it was't able to get past the initial
buffer size. I believe what I did was:
1) Set proc_sys_kernel_osrelease to NULL
2) Set MAX_G_STRING_SIZE to 16 so it will overflow on a typical EL OS
release string which is 20 characters long
It would be great if you can confirm this -- it is possible I did
something wrong here.
Regarding this particular bug -- how should we fix this? There are
currently two issues:
1) The OS release is truncated in the web frontend
2) The warning "slurpfile() read() buffer overflow on file
/proc/sys/kernel/osrelease" is displayed multiple times during RPM
installation (possibly because gmond was called to generate conf files
etc.)
Can we potentially increase MAX_G_STRING or have
proc_sys_kernel_osrelease buffer size resize dynamically?
Cheers,
Bernard
------------------------------------------------------------------------------
Free Software Download: Index, Search & Analyze Logs and other IT data in
Real-Time with Splunk. Collect, index and harness all the fast moving IT data
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business
insights. http://p.sf.net/sfu/splunk-dev2dev
_______________________________________________
Ganglia-developers mailing list
Ganglia-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-developers
