On Wednesday, August 17, 2016 9:45:09 PM EDT Michael Oswald wrote:
> Hello,
> I had a first look into the source code and also some small fixes for
> issues reported by valgrind.
>
> In three cases a delete was used when a delete [] should have been:
> midiseq.cpp L 183:
> should be:
>
> delete [] _clockAveragerStages;
>
> wavepreview.cpp L 28 + 29:
>
> should be:
> delete [] tmpbuffer;
> delete [] srcbuffer;
Fixed in git master.
Thanks. ++credit in the ChangeLog.
> Then a few questions:
>
> in lv2host.cpp:
>
> from lines 2289:
>
> if(_nPname != 0)
> {
> _portName = lilv_node_as_string(_nPname);
> lilv_node_free(_nPname);
> }
>
>
> and then:
>
> line 2335:
>
> cPorts->push_back(LV2ControlPort(_port, i, 0.0f, _portName,
> _portSym, _cType, isCVPort));
>
>
> The thing is, valgrind reports reading from memory locations which have
> been freed. In this case it concerns the _portName variable which is
> just a const char* pointer.
> Unfortunately, since the _nPname node is freed, the pointer points into
> garbage since no copy is returned, which could potentially lead to a
> crash. This is also for other variables kept, but pointing into a now
> deleted node.
>
> So most probably the node should be freed later on in the code. It
> probably works most of the time when there are less allocations in
> between, but in multi-threaded, multi-core you never know.
[@ Andrew] if you are watching, I hope this wasn't the type of thing
you meant when you said you had to hack LV2? I recall you said
something like that about memory problems.
Darn, I had hoped that by replacing the older built-in LV2 versions
with updated 'stock' or system version (user's configure choice)
that all would be well.
[@ Michael ] I made changes there recently, replacing Andrew's
LV2 version with a more recent 'stock' version.
I'll have to compare with old releases since I wiped out the old version.
I wonder if this is what Andrew fixed.
> By looking at this I saw that e.g. STL containers or things like the
> boost libraries or even QT Framework general stuff is not used much, so
> is there a design decision behind this?
>
> Reason I ask is I come from a very different SW development area (I
> develop and maintain a mission control system which currently flies 6
> satellites) and, especially for allocation/dealloction, we rely heavily
> on STL/boost/Poco.
Do you mean MusE using STL + friends specifically for memory allocation,
or for general use?
There's a general mixture depending on who's coding and what the task is.
Tons of STL and Qt template stuff. But no boost, yet.
I think you are correct in that nowhere do we use STL or Qt for the
actual allocation of memory. Just malloc or new, and some system functions
for special aligned memory for audio buffers.
When we use STL containers we usually just use the default allocator,
but there are a few sections where a special pool is used for RT.
I want to use pools more because there are still places in the RT code
which may cause a container to allocate in RT.
I looked at boost a few times. I know it has good features for these things.
Ardour uses (used?) it. But we've never used it in this app before.
Inertia...
> So are there some coding rules/principles/does and don'ts?
I can't speak for this loose conglomeration of nuts we call a project,
but we each have our ways.
Myself, I know that usually you're supposed to prefer functions from
the operating system over C or C++ functions.
For example in Windows I usually use their allocation functions,
especially for the more esoteric memory needs.
In MusE we probably /should/ be using all Qt functions all the time.
But we don't always.
Maybe it's a little bit like 'hedging your bets' - maybe left over from
the old days when MusE was young and Qt was not a certainty yet
at version 2 (or less?) - where you hope for best cross-platform
compatibility and so take the lowest common tool which is STL.
Some of the code is really old so maybe that's why there's
heavier emphasis on STL.
And I tend to code as 'when in Rome...' so I follow what others
have done in the project and thus lean towards STL more often.
STL seems more portable.
With your experience, what do you think of our template lib situation?
Bit of a dog's breakfast?
Do you recommend that we stick with only one template lib and
is a mixture a bad thing?
Florian wanted to start MusE-3 from scratch with consistent use
of a boost-like library, I forget which, and using locks instead our
current 'synchronized just in time' realtime model.
Ask away if you need help navigating MusE.
Tim.
>
> lg,
> Michael
------------------------------------------------------------------------------
_______________________________________________
Lmuse-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/lmuse-developer
