dovecot - Sep 2018 - v2.3.3 rc1 - Error: sieve: !!BUG!!: Binary compiled from dovecot.sieve is still corrupt

On 27/09/2018 13:40, Stephan Bosch wrote:
>> Address   Line  Code
>> 00000000:       DEBUG BLOCK: 3
>> 00000001:       EXTENSIONS [1]:
>> 00000002:         vacation
>> 00000004:    2: VACATION
>> 00000007:    4:   seconds: NUM 5
>> 00000009:         Binary is corrupt.
>>
>> The line numbers differs and 86400 is read as 5.  It is like it has
>> forgotten the size of an integer or is confused about endianness.
>> There is something strange, like an #if that guesses wrong.  At least
>> I have somewhere to start looking.
>>
>> Thank you for checking at your end, I was worried the RC had
>> introduced an error and your result suggests not.  RCs are for testing
>> and I am.
>
> The number is stored as a chain of bytes of which the most significant
> bit indicates whether the next byte still belongs to the number. If this
> bit is somehow interpreted wrong, the first byte of this number would
> read as 5, thereby returning '5' as the result and ignoring
subsequent
> bytes (causing corruption at the next item to read).
>
> Since you're using SunOS, your compiler may be doing something funky.
> Which compiler is used anyway? Perhaps different versions for the
> Dovecot releases that do and don't work?
It was studio cc.  gcc doesn't make it through configure and I didn't 
ask why.  I have some other things to do but will look at this again 
later.  Thank you for the byte code explanations.  The coding at this 
point is hard to follow with the pointers-to-functions and #defines.



James.

> On 27 Sep 2018, at 16.53, James <list at xdrv.co.uk> wrote:
> 
> On 27/09/2018 13:40, Stephan Bosch wrote:
> 
>>> Address   Line  Code
>>> 00000000:       DEBUG BLOCK: 3
>>> 00000001:       EXTENSIONS [1]:
>>> 00000002:         vacation
>>> 00000004:    2: VACATION
>>> 00000007:    4:   seconds: NUM 5
>>> 00000009:         Binary is corrupt.
>>> 
>>> The line numbers differs and 86400 is read as 5.  It is like it has
>>> forgotten the size of an integer or is confused about endianness.
>>> There is something strange, like an #if that guesses wrong.  At
least
>>> I have somewhere to start looking.
>>> 
>>> Thank you for checking at your end, I was worried the RC had
>>> introduced an error and your result suggests not.  RCs are for
testing
>>> and I am.
>> 
>> The number is stored as a chain of bytes of which the most significant
>> bit indicates whether the next byte still belongs to the number. If
this
>> bit is somehow interpreted wrong, the first byte of this number would
>> read as 5, thereby returning '5' as the result and ignoring
subsequent
>> bytes (causing corruption at the next item to read).
>> 
>> Since you're using SunOS, your compiler may be doing something
funky.
>> Which compiler is used anyway? Perhaps different versions for the
>> Dovecot releases that do and don't work?
> 
> It was studio cc.  gcc doesn't make it through configure and I
didn't ask why.  I have some other things to do but will look at this again
later.  Thank you for the byte code explanations.  The coding at this point is
hard to follow with the pointers-to-functions and #defines.

Can you share a little bit more info on how did the compile (or configure even)
fail with gcc on Solaris 11?

as I have no problems in compiling dovecot and pigeonhole on my Solaris 11.3
system with gcc. The version that ships with my Solaris is 4.5.2.

I also have Sun Studio 12.5 installed but I have not even tried to compile
dovecot wit that yet.

Sami

On 27/09/2018 16:14, Sami Ketola wrote:
>> It was studio cc.  gcc doesn't make it through configure and I
didn't ask why.
>
> Can you share a little bit more info on how did the compile (or configure
even) fail with gcc on Solaris 11?

$ ./configure $ARGS
...
checking Linux compatible mremap()... no
checking whether shared mmaps get updated by write()s... no
checking whether fd passing works... no
configure: error: fd passing is required for Dovecot to work

Which in the log corresponds to:

configure:22685: ./conftest
./configure[2026]: eval: line 1: 22335: Memory fault(coredump)


Appears to the option "-mfunction-return=thunk" that cause the
problem,
remove and no core dump.  Older gccs do not have -mfunction-return.




> as I have no problems in compiling dovecot and pigeonhole on my Solaris
11.3 system with gcc. The version that ships with my Solaris is 4.5.2.
Strictly speaking Solaris 11 does not ship with gcc, one can install it 
[from the OS vendor] with pkg and there is a choice of versions.

# pkg list -a | grep gcc-c


I have gcc versions installed: 4.9.5, 5.5.0, 6.4.0, 7.3.0 and 8.2.0.


> I also have Sun Studio 12.5 installed but I have not even tried to compile
dovecot wit that yet.
Current Release - Oracle Developer Studio 12.6.





James.