imatix / gsl

iMatix GSL code generator
http://www.imatix.com
GNU General Public License v3.0
539 stars 107 forks source link

Crash on counting subelements #141

Open vyskocilm opened 7 years ago

vyskocilm commented 7 years ago

I have an expression causing crash in gsl.

Example project

<project name = "fty-metric-composite" script = "zproject.gsl"

<main name = "name" service = "1">Name
    <install type = "systemd-tmpfiles" />
    <install type = "config" name = "name.cfg.example" />
</main>

diff --git a/zproject.gsl b/zproject.gsl
index cb9206f..13c07fe 100644
--- a/zproject.gsl
+++ b/zproject.gsl
@@ -69,6 +69,8 @@ project->license. ?= "Copyright (c) the Authors"

 project.has_main = (count (main) > 0)
 project.exports_classes = (count (class, !defined (class.private)) > 0)
+project.has_install = (count (main, (count (main.install) > 0)) > 0)
+echo "project.has_install=$(project.has_install)"
 project.generated_warning_header ?= "\
################################################################################
 #  THIS FILE IS 100% GENERATED BY ZPROJECT; DO NOT EDIT EXCEPT EXPERIMENTALLY      #

Then running gsl file.xml

Clean-memory assertion failed - <Unknown> (0)
Details are in memtrace.xml
Aborted (core dumped)

(gdb) bt
#0  0x00007fec0bafb8d7 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:55
#1  0x00007fec0bafccaa in __GI_abort () at abort.c:78
#2  0x000000000044b4a3 in mem_assert_ ()
#3  0x0000000000404227 in main ()

cat memtrace.xml
<?xml version="1.0"?>
<transaction>
    <block index="0" size="136" file="<Unknown>" line="0" pointer="0x1a1e180" />
</transaction>
evoskuil commented 7 years ago

Possibly related: https://github.com/imatix/gsl/issues/21

jschultz commented 7 years ago

Other than the fact that both #21 and this issue are memory leaks I don't see any reason to think they are related. The different size of the leaked memory block (16/136) makes it unlikely that they are the same thing.

The good news is that this bug is nothing more serious than a memory leak and should not affect the output files. The bad news is that tracking memory leaks can be tricky. In any case the first thing we need to do is build GSL with debugging - see https://github.com/imatix/gsl/issues/21#issuecomment-31239830 - so that we get a file and line number in the memtrace.xml If someone could do that I'd be happy to take a quick look at how complex the problem seems to be.

vyskocilm commented 7 years ago

I rebuild gsl after export DEBUG=1, but the memtrace is almost the same

cat memtrace.xml
<?xml version="1.0"?>
<transaction>
    <block index="0" size="136" file="<Unknown>" line="0" pointer="0x14a6a80" />
</transaction>

If there are more ways to reproduce, I'll do it.

jschultz commented 7 years ago

If DEBUG is set you should definitely get a value for the attributes 'file' and 'line' in memtrace.xml. Take a look in sflmem.h/.c to see how it works. I'm not familiar with the current build procedures but a quick look tell me that 'make debug' should do the trick.