Bug 1402582

"""
Okay thanks for the report. Switching to some colm/ragel development soon and I hope to get this sorted out!

Regards,
 Adrian
"""

by upstream developer.

rubygem-puma also FTBFS due to this
https://koji.fedoraproject.org/koji/taskinfo?taskID=17289704

Created attachment 1241664 [details]
Ragel backtrace.

This is the core file and backtrace from build of rubygem-puma:

```
# gdb core.28970 
GNU gdb (GDB) Fedora 7.12-39.fc26
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "armv7hl-redhat-linux-gnueabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
[New LWP 28970]
Reading symbols from /usr/bin/ragel...Reading symbols from /usr/lib/debug/usr/bin/ragel.debug...done.
done.
Core was generated by `ragel ext/puma_http11/http11_parser.rl -C -G2 -I ext/puma_http11 -o ext/puma_ht'.
Program terminated with signal SIGABRT, Aborted.
#0  0xb6bb8140 in raise () from /lib/libc.so.6
Missing separate debuginfos, use: dnf debuginfo-install glibc-2.24.90-28.fc26.armv7hl libgcc-6.3.1-1.fc26.armv7hl libstdc++-6.3.1-1.fc26.armv7hl
(gdb) where
#0  0xb6bb8140 in raise () from /lib/libc.so.6
#1  0xb6bb9ab8 in abort () from /lib/libc.so.6
#2  0xb6bb06b0 in __assert_fail_base () from /lib/libc.so.6
#3  0xb6bb0790 in __assert_fail () from /lib/libc.so.6
#4  0xb6f07294 in colm_tree_downref (prg=prg@entry=0xb6f19fac, sp=<optimized out>, tree=tree@entry=0xb6cf20b0 <lock>) at tree.c:958
#5  0xb6f0c74c in colm_execute_code (prg=0xb6f19fac, prg@entry=0x80c9e588, exec=0x1, exec@entry=0xbeaba000, sp=<optimized out>, instr=0xb6f58010 "", instr@entry=0x7f6f7134 <parser_rootCode> "\377\b\t")
    at bytecode.c:3258
#6  0xb6f187e8 in colm_execute (prg=prg@entry=0x80c9e588, exec=exec@entry=0xbeaba000, code=0x7f6f7134 <parser_rootCode> "\377\b\t") at bytecode.c:417
#7  0xb6f1908c in colm_run_program (prg=prg@entry=0x80c9e588, argc=argc@entry=4, argv=argv@entry=0xbeaba078) at program.c:217
#8  0x7f5c3e30 in SectionPass::reduceFile (this=this@entry=0x80c9e3f8, inputFileName=<optimized out>) at reducer.cc:370
#9  0x7f5aeea4 in InputData::parseReduce (this=this@entry=0xbeaba278) at inputdata.cc:740
#10 0x7f5afa6c in InputData::processReduce (this=0xbeaba278) at inputdata.cc:777
#11 0x7f59df64 in main (argc=-1225820512, argv=0xb6ef6d30 <vtable for std::basic_ios<char, std::char_traits<char> >>) at main.cc:801
(gdb) quit
```

BTW this does not fail always, just every other run ...

Now it seems that colm itself won't build (sometimes) on armv7hl when doing bootstrap (during build):

https://koji.fedoraproject.org/koji/taskinfo?taskID=17408183

./bootstrap1 -c -o gen/parse2.c -e gen/if2.h -x gen/if2.cc colm.lm
make[2]: Leaving directory '/builddir/build/BUILD/colm-0.13.0.4/src'
lt-bootstrap1: tree.c:958: colm_tree_downref: Assertion `tree->refs > 0' failed.
make[2]: *** [Makefile:1564: gen/parse2.c] Aborted (core dumped)

*** Bug 1423299 has been marked as a duplicate of this bug. ***

*** Bug 1423469 has been marked as a duplicate of this bug. ***

Even if compiling with -O0, colm won't build on armv7hl...

This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle.
Changing version to '26'.

This should hit us also in rawhide.

------
x86_64
------

bytecode.c: In function 'rcode_downref':
bytecode.c:4723:11: warning: variable 'inserted' set but not used [-Wunused-but-set-variable]
     uchar inserted;
           ^~~~~~~~
bytecode.c:4735:11: warning: variable 'inserted' set but not used [-Wunused-but-set-variable]
     uchar inserted;
           ^~~~~~~~

-------
armv7hl
-------

bytecode.c: In function 'rcode_downref':
bytecode.c:68:5: warning: assignment makes integer from pointer without a cast [-Wint-conversion]
   i = (type) w; \
     ^
bytecode.c:109:26: note: in expansion of macro 'read_type'
 #define read_tree( i )   read_type( tree_t*, i )
                          ^~~~~~~~~
bytecode.c:4527:4: note: in expansion of macro 'read_tree'
    read_tree( w );
    ^~~~~~~~~
bytecode.c:4723:11: warning: variable 'inserted' set but not used [-Wunused-but-set-variable]
     uchar inserted;
           ^~~~~~~~
bytecode.c:4735:11: warning: variable 'inserted' set but not used [-Wunused-but-set-variable]
     uchar inserted;
           ^~~~~~~~
bytecode.c: In function 'colm_rcode_downref_all':
bytecode.c:4529:4: warning: 'w' may be used uninitialized in this function [-Wmaybe-uninitialized]
    colm_tree_downref( prg, sp, w );
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
bytecode.c:4526:12: note: 'w' was declared here
    tree_t *w;
            ^
In file included from bytecode.c:24:0:
bytecode.c: In function 'colm_execute_code':
include/colm/bytecode.h:513:80: warning: 'w' may be used uninitialized in this function [-Wmaybe-uninitialized]
  ( ( sp == prg->sb_beg ? (sp = vm_bs_add(prg, sp, 1)) : 0 ), (*((type*)(--sp)) = (i)) )
                                                                                ^
bytecode.c:629:11: note: 'w' was declared here
    word_t w;
           ^



I think that's where all weird stuff could happen...

(In reply to Igor Gnatenko from comment #10)
> <snip>
> I think that's where all weird stuff could happen...

Well, the warnings on 32 bit you pointed out is actually easy to fix (I know the reason for these warnings), however even after fixing these warnings, colm's abort() on this bugzilla does not disappear...

Created attachment 1259892 [details]
Patch to kill warnings specific to 32 bit

FYI here is the patch to kill warnings specific to 32 bit

I'm out of ideas. Probably I will go and downgrade ragel, so it will not use colm at all...

(In reply to Igor Gnatenko from comment #13)
> Probably I will go and downgrade ragel, so it will not use
> colm at all...

I won't oppose to this. If someone would fix this colm issue in the future, then we can try newer ragel again.

(In reply to Mamoru TASAKA from comment #14)
> (In reply to Igor Gnatenko from comment #13)
> > Probably I will go and downgrade ragel, so it will not use
> > colm at all...
> 
> I won't oppose to this. If someone would fix this colm issue in the future,
> then we can try newer ragel again.

What about a compatibility package ¹ (maybe named ragel-nocolm) to support ragel on architectures where colm obviously does not work? Then colm could be marked with ExcludeArch ².
¹ https://fedoraproject.org/wiki/Packaging:Naming?rd=Packaging:NamingGuidelines#Multiple_packages_with_the_same_base_name
² https://fedoraproject.org/wiki/Packaging:Guidelines#Architecture_Build_Failures

ragel 0.13.0.5 is released, but this issue is not fixed yet.

I did recently ~20 builds of Puma and it seems that recent ragel-7.0.0.10-1.fc28 does not core dump anymore.

Thanks for the new information. I'll check and verify again.

Still FTBFS in rawhide.

The versions of ragel/colm have been bumped. I did a scratch build of trojita, while it failed it didn't appear to fail in the same spot on the arm build.

https://koji.fedoraproject.org/koji/taskinfo?taskID=28096880