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@openindiana.org:
> On 15-02-25 18:58, s...@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@openindiana.org
> https://openindiana.org/mailman/listinfo/oi-dev
_______________________________________________
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev
