-
Notifications
You must be signed in to change notification settings - Fork 462
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Inconsistent import identifiers + memory leak #1160
Comments
Would it help if that issue was broken up into different tasks? There seems to be a lot of different bugs filed under one all encompassing issue. This might help carve off some of the bugs into actionable items. For instance, |
I think this is one issue in one part of code, and this code needs to be torn apart a bit. It is kind of orthogonal to the problems reported. |
The memory leaks should be fixed by #1330. |
will try to provide test case for the leak |
To clarify my intentions about better C-API I have opened #1368 for discussion. |
@saper can you give an update what real issues are still relevant at the time beeing? Thanks! |
Any updates here? |
Closing this due to inactivity, problems should be resolved. Re-open if not! |
I just spent some time analyzing sass/node-sass#894 (thanks @jameslnewell) which ends up to be a consequence of problems reported also as #1040 #1041 #1035 (comment)
Testing done using:
Here are the results of my tests:
https://gist.github.com/saper/5263902b8446431ae136
libsass
is not consistent about what is being put intostyle_sheets
- sometimes it is a short import name, sometimes file base name.There is also a memory leak in context.cpp#L330 - in case of two-strings.js an AST compiled as a result of the first import gets overwritten when we are storing a second AST under the same name
foobar
issue-894-two-strings.out#L14.It should be decided what do the short import names really mean in the context of custom importers (that can return random content every time they are called).
Looks to me that
add_file
andadd_string
need some love. The cleanup there can also help resolve some memory allocation issues hiding in the code (for example only internally allocated strings should end up on thesources
list, and not those provided by the caller).Generally I think there too many single-purpose little lists, may be it would be better to have something similar to the parser input queue (with items similar to today's
Sass_Queued
) that contains a directory of all sources:those source material could be related to the output information:
The text was updated successfully, but these errors were encountered: