-
Notifications
You must be signed in to change notification settings - Fork 106
Crash on counting subelements #141
Comments
Possibly related: #21 |
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 #21 (comment) - 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. |
I rebuild gsl after export DEBUG=1, but the memtrace is almost the same
If there are more ways to reproduce, I'll do it. |
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. |
I have an expression causing crash in gsl.
Example project
Then running gsl file.xml
The text was updated successfully, but these errors were encountered: