[Top][All Lists]

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

[Help-glpk] [Fwd: GLPK 4.38 Re-entrancy 64-bit windows]

From: Andrew Makhorin
Subject: [Help-glpk] [Fwd: GLPK 4.38 Re-entrancy 64-bit windows]
Date: Fri, 11 May 2012 02:28:47 +0400

-------- Forwarded Message --------
From: Nicholas Nash <address@hidden>
To: address@hidden
Subject: GLPK 4.38 Re-entrancy 64-bit windows
Date: Thu, 10 May 2012 20:12:13 +0100



I have some legacy code that is using GLPK 4.38, despite much searching
online I can’t get definitive answers to some questions.


Is GLPK 4.38 re-entrant? The code I have is multi-threaded and running
in a Windows 64-bit environment, calling GLPK from C#.

A single GLPK problem is only ever accessed in a single thread; although
many threads create their own GLPK problems and solve them.


I can see code in glplib02.c that allocates thread local storage, so am
I correct that the usage I have described above is safe?


Despite using GLPK as above, I still occasionally see this error


xfree: memory allocation error

Error detected in file ..\src\glplib07.c at line 181


Since I’m not out of memory, guessing at the code makes it looks like
there was an unmatched free/delete (or there was a threading issue
related to a counter).


Is this a known bug in GLPK 4.38, or is the bug more likely to be mine?

Would moving to a later version help?





reply via email to

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