[CWB] Segmentation fault

[Hardie, Andrew]

I had my fingers crossed the problem would only be with the specific variable in the previous error you reported, but actually I was afraid of this.

The underlying issue is that there are (at least) two ways to define global variables in C:


  *   In a source file, with "extern" declarations in other source/header files
  *   In a header file, which creates a copy of the definition in each source file the header is included in; the multiple copies of identical variables in global scope are later merged by the linker.

The former is the newer and recommended way, and the latter is older and AFAIK Unix-only.

CWB uses both, but mostly the latter.  In GCC, which one works depends on whether it is in "common" mode (both work) or "no-common" mode (only the former method words).

In older GCCs - including v 8 which is in use on Debian buster -  "common" is the default. In GCC 10, "no-common" is default. Changelog (https://gcc.gnu.org/gcc-10/changes.html)  says


  *   GCC now defaults to -fno-common. As a result, global variable accesses are more efficient on various targets. In C, global variables with multiple tentative definitions now result in linker errors. With -fcommon such definitions are silently merged during linking.

Fedora favours cutting-edge GCC whereas Debian is conservative. Thus why we have hit this problem first in Fedora.

I strongly suspect, Maarten, that your Fedora distro uses gcc 10 or gcc 11.


The wording of the gcc manuals over the ages is quite amusing, by the way, as it goes from assuming that of course you want "common" to an equally strong assumption that only smelly legacy code would want "common".

=============================================================================

v2:
-fno-common
Allocate even uninitialized global variables in the bss section of the object file, rather than generating them as common blocks. This has the effect that if the same variable is declared (without extern) in two different compilations, you will get an error when you link them. The only reason this might be useful is if you wish to verify that the program will work on other systems which always work this way.

v8:
-fno-common
In C code, this option controls the placement of global variables defined without an initializer, known as tentative definitions in the C standard. Tentative definitions are distinct from declarations of a variable with the extern keyword, which do not allocate storage.
Unix C compilers have traditionally allocated storage for uninitialized global variables in a common block. This allows the linker to resolve all tentative definitions of the same variable in different compilation units to the same object, or to a non-tentative definition. This is the behavior specified by -fcommon, and is the default for GCC on most targets. On the other hand, this behavior is not required by ISO C, and on some targets may carry a speed or code size penalty on variable references.
The -fno-common option specifies that the compiler should instead place uninitialized global variables in the data section of the object file. This inhibits the merging of tentative definitions by the linker so you get a multiple-definition error if the same variable is defined in more than one compilation unit. Compiling with -fno-common is useful on targets for which it provides better performance, or if you wish to verify that the program will work on other systems that always treat uninitialized variable definitions this way.
v11:
-fcommon
In C code, this option controls the placement of global variables defined without an initializer, known as tentative definitions in the C standard. Tentative definitions are distinct from declarations of a variable with the extern keyword, which do not allocate storage.
The default is -fno-common, which specifies that the compiler places uninitialized global variables in the BSS section of the object file. This inhibits the merging of tentative definitions by the linker so you get a multiple-definition error if the same variable is accidentally defined in more than one compilation unit.
The -fcommon places uninitialized global variables in a common block. This allows the linker to resolve all tentative definitions of the same variable in different compilation units to the same object, or to a non-tentative definition. This behavior is inconsistent with C++, and on many targets implies a speed and code size penalty on global variable references. It is mainly useful to enable legacy code to link without errors.

====================================================================
Ah well.

The question is what to do. Solution 1. Add -fcommon to all GCC calls in the makefile. Solution 2. Bite the bullet and make each global variable be defined in one place only with an extern declaration in a header file.

STEFAN - any thoughts? My instinct is the latter - it will be easy enough for me to switch to -fno-common on Debian and allow the resulting build errors to find all the variables in question!

best

Andrew.

From: cwb-bounces at sslmit.unibo.it <cwb-bounces at sslmit.unibo.it> On Behalf Of Maarten Janssen
Sent: 05 May 2020 09:19
To: CWBdev Mailing List <cwb at sslmit.unibo.it>
Subject: Re: [CWB] Segmentation fault

The fedora issue changed - but now actually throws a lot more error messages, I guess because the libraries that are being loaded are partially overlapping, this should be the crucial bit, but it then goes on for various pages with duplications:

gcc -O2 -Wall -fPIC -m64   -DUSE_TERMCAP -DUSE_READLINE -DCWB_REGISTRY_DEFAULT_PATH=\""/usr/local/cwb-3.4.22/share/cwb/registry"\" -DCOMPILE_DATE=\""Tue 05 May 2020 04:16:03 AM EDT"\" -DCWB_VERSION=\"3.4.22\" -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include     -o cqp llquery.o cqp.o symtab.o eval.o tree.o options.o corpmanag.o regex2dfa.o output.o ranges.o builtins.o groups.o targets.o matchlist.o concordance.o parse_actions.o attlist.o context_descriptor.o print-modes.o ascii-print.o sgml-print.o html-print.o latex-print.o variables.o print_align.o macro.o hash.o table.o parser.tab.o lex.yy.o dummy_auth.o /home/mjanssen/cwb/cqp/../cl/libcl.a   -lm   -lpcre -lglib-2.0    -lreadline -lhistory -lncurses -ltinfo
/usr/bin/ld: cqp.o:(.bss+0x2acaa8): multiple definition of `signal_handler_is_installed'; llquery.o:(.bss+0x2ac268): first defined here
/usr/bin/ld: cqp.o:(.bss+0x2acaac): multiple definition of `EvaluationIsRunning'; llquery.o:(.bss+0x2ac26c): first defined here
/usr/bin/ld: cqp.o:(.bss+0x2ac938): multiple definition of `silent'; llquery.o:(.bss+0x2ac0f8): first defined here
/usr/bin/ld: cqp.o:(.bss+0x2acab0): multiple definition of `exit_cqp'; llquery.o:(.bss+0x2ac270): first defined here
/usr/bin/ld: cqp.o:(.bss+0x2ac8f8): multiple definition of `child_process'; llquery.o:(.bss+0x2ac0b8): first defined here
/usr/bin/ld: cqp.o:(.bss+0x2acaa0): multiple definition of `current_corpus'; llquery.o:(.bss+0x2ac260): first defined here


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://liste.sslmit.unibo.it/pipermail/cwb/attachments/20200505/71e691c2/attachment-0001.html>