octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #47372] Memory leaks and segmentation faults i


From: Rik
Subject: [Octave-bug-tracker] [bug #47372] Memory leaks and segmentation faults in Octave
Date: Wed, 30 Mar 2016 17:03:38 +0000
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:43.0) Gecko/20100101 Firefox/43.0

Follow-up Comment #63, bug #47372 (project octave):

I think there may have been a verbatim block missing after "Changing the
nil_rep function to do this instead:".  Regardless, I get the idea.  It sure
is a pain to develop for Windows.

I think your intuition is correct.  The usual method for exporting symbols in
Windows is __declspec.  You might try this thread
http://stackoverflow.com/questions/225432/export-all-symbols-when-creating-a-dll#226017.

However, it seems that Windows may not allow non-public data members to be
exported.  You can see if you understand the documentation better than I do
(https://msdn.microsoft.com/en-us/library/a90k134d.aspx).  One quick test
would be to use your last attempt and put nil_rep in as a public variable
rather than a private one.

This thread also looked germane:
http://stackoverflow.com/questions/19373061/what-happens-to-global-and-static-variables-in-a-shared-library-when-it-is-dynam.
 It appears that each thread may get its own copy of a static variable.


In the case of Unix-like environments (like Linux), the dynamic libraries,
called "shared objects" with extension .so export all extern global variables
(or functions). In this case, if you do load-time linking from anywhere to a
shared object file, then the global variables are shared, i.e., linked
together as one. Basically, Unix-like systems are designed to make it so that
there is virtually no difference between linking with a static or a dynamic
library. Again, ODR applies across the board: an extern global variable will
be shared across modules, meaning that it should have only one definition
across all the modules loaded.


That seems to be what is happening on Linux, and what definitely does not
happen on Windows.


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?47372>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]