[oi-dev] Valgrind

[stes at telenet.be]

For the moment I'll disable the Linux epoll() support in OpenSmalltalk.

Squeak (the parent project of OpenSmalltalk) supports select() and without epoll(), that is, with a select() based implementation, valgrind prints no warning on possibly uninitialized memory.

At the time I enabled epoll support in OpenSmalltalk on OpenIndiana, this was due to the OpenSmalltalk "configure" script which at the time did not have a --disable-epoll switch.   When OpenSmalltalk configure found the header file,

       #include <sys/epoll.h>

then configure would automatically enable epoll support (based on the presence of the header file on the build server).

But fortunately now there is an option --disable-epoll for OpenSmalltalk configure.

This switch (--disable-epoll) was not available at first.

----- Op 15 feb 2025 om 19:59 schreef Paul Floyd via oi-dev oi-dev at openindiana.org:

> On 15-02-25 18:58, stes at telenet.be wrote:
>> 
>> valgrind can run the OpenSmalltalk (a dialect or fork of Squeak) interpreter on
>> OpenIndiana.
>> 
>> I reported a bug (not sure this is really a bug) for it  #17199.
>> 
>> This relates to https://illumos.org/man/7/epoll  because epoll can be enabled
>> for OpenSmalltalk on OpenIndiana.
>> 
>> This is to my knowledge, different from Solaris, as the Illumos kernel supports
>> Linux epoll.
> 
> If you want Valgrind bugs fixed than you're best off reporting it to
> https://bugs.kde.org. No promises - we have a big backlog and not enough
> contributors (something that you might be familiar with).
> 
> Looking at https://www.illumos.org/issues/17199
> 
> your error is
> 
> ==3215== Syscall param write(buf) points to uninitialised byte(s)
> ==3215==    at 0x7FFEBE94A: __write (in /lib/amd64/libc.so.1)
> ==3215==    by 0x7FFE90550: epoll_ctl (in /lib/amd64/libc.so.1)
> 
> The syscall is 'write', not 'epoll'.
> 
> Without the source I can't be sure what is happening but this kind of
> error is quite common.
> 
> For syscalls that use either just scalar or array builtin types or fixed
> structs (like the 'stat' family) we can check the scalar/array/fields of
> the struct. Generic syscalls like 'read' and 'write' are a problem. All
> we get is a file descriptor, pointer and a length. We don't know what
> the pointer points to (we don't do any source analysis). That means that
> if the struct has any holes or padding amd hasn't been memset to zero we
> will see uninitialised bytes. We have no way to tell apart struct fields
> that from holes or padding.
> 
> That means that you have two choices.
> 
> 1. Ensure that the struct gets memset to 0.
> 2. Use the Valgrind suppression mechanism to suppress the error.
> 
> A+
> Paul
> 
> 
> _______________________________________________
> oi-dev mailing list
> oi-dev at openindiana.org
> https://openindiana.org/mailman/listinfo/oi-dev