ERGO-Code
HIGHS 1.11.0 (+1) Crashes for MIP Problems Only - Works for LP and LP's called within an SLP Executive.
Dear HIGHS;
Just downloaded the latest HiGHS-v1.11.0+1 binaries.
The previous reported issue that the HIGHS 1.10.0 label / tag was used for the HIGHS 1.11.0 is now fixed but HIGHS crashes only when running MIP problems inside the HIGHS_run() routine. HIGHS LP works and also works when called inside an SLP executive.
I reviewed and compared the highs_c_api.h for 1.11.0 and 1.10.0 and I did not see any relevant C API modifications from 1.11.0 to 1.10.0.
All the best - Jeff
Running HiGHS 1.11.0 (git hash: 364c83a51e): Copyright (c) 2025 HiGHS under MIT licence terms Cols: 2 lower bounds less than or equal to -1e+20 are treated as -Infinity Cols: 2 upper bounds greater than or equal to 1e+20 are treated as +Infinity Rows: 1432 lower bounds less than or equal to -1e+20 are treated as -Infinity SOLVE forrtl: severe (157): Program Exception - access violation Image PC Routine Line Source libhighs.dll 0000000070D59EB0 Unknown Unknown Unknown libhighs.dll 0000000070D41512 Unknown Unknown Unknown libhighs.dll 0000000070D26C72 Unknown Unknown Unknown libhighs.dll 0000000070D67D1B Unknown Unknown Unknown libhighs.dll 0000000070D58043 Unknown Unknown Unknown IMPLpresolver.dll 00007FFD2B95EBEB Unknown Unknown Unknown IMPL.exe 00007FF617CCFA32 Unknown Unknown Unknown IMPL.exe 00007FF617CF43CB Unknown Unknown Unknown IMPL.exe 00007FF617D39B10 Unknown Unknown Unknown KERNEL32.DLL 00007FFD9850E8D7 Unknown Unknown Unknown ntdll.dll 00007FFD98FFC5DC Unknown Unknown Unknown
@jeffreydeankelly2 can you provide a reproducible example? The binaries work for me in Julia.
What happens if you compile HiGHS yourself instead of using the Julia binaries? Note that there are some minor changes in the header: some int become HighsInt etc.
I'm also going to make an assumption: have you written a custom callback? If so, what is it? That's probably where the bug is.
When I comment out the HIGHS callback in 1.11.0, HIGHS runs without raising any exception however it does not give the correct global solution for the MIP - this is another issue.
I believe from the lp_data/HighsCallback.h documentation that the underlying issue is that the HighsCallbackDataOut data structure has changed i.e., cutpool_num_nz removed and the HighsCallbackDataIn data structure has significantly changed as HIGHS 1.10.0 only has user_interrupt.
I did not see these changes reported in the HIGHS 1.11.0 Release Notes.
Also, since I am interfacing HIGHS to Fortran by calling its C API's directly, the changes to HighsCallbackDataIn may no longer be possible to interface to it.
/**
- Struct to handle callback output data
/
struct HighsCallbackOutput {
Highs highs = nullptr;
HighsLogType log_type;
double running_time;
HighsInt simplex_iteration_count;
HighsInt ipm_iteration_count;
HighsInt pdlp_iteration_count;
double objective_function_value;
int64_t mip_node_count;
int64_t mip_total_lp_iterations;
double mip_primal_bound;
double mip_dual_bound;
double mip_gap;
std::vector
mip_solution; HighsInt cutpool_num_col; HighsInt cutpool_num_cut; std::vector<HighsInt> cutpool_start; std::vector<HighsInt> cutpool_index; std::vector cutpool_value; std::vector cutpool_lower; std::vector cutpool_upper; userMipSolutionCallbackOrigin user_solution_callback_origin;
operator HighsCallbackDataOut() const; };
struct HighsCallbackInput {
Highs* highs = nullptr;
bool user_interrupt = false;
bool user_has_solution = false;
std::vector
HighsStatus setSolution(HighsInt num_entries, const double* value);
HighsStatus setSolution(HighsInt num_entries, const HighsInt* index, const double* value);
HighsStatus repairSolution();
operator HighsCallbackDataIn() const; HighsCallbackInput operator=(const HighsCallbackDataIn& data_in); };
On Sun, Jun 8, 2025 at 6:42 PM Oscar Dowson @.***> wrote:
odow left a comment (ERGO-Code/HiGHS#2400) https://github.com/ERGO-Code/HiGHS/issues/2400#issuecomment-2954310933
What happens if you compile HiGHS yourself instead of using the Julia binaries?
— Reply to this email directly, view it on GitHub https://github.com/ERGO-Code/HiGHS/issues/2400#issuecomment-2954310933, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALHONEFHI3B2YCSLJSYPT6D3CS34ZAVCNFSM6AAAAAB627CHQOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSNJUGMYTAOJTGM . You are receiving this because you were mentioned.Message ID: @.***>
--
I M P L - " M a k i n g O p t i m i z a t i o n a n d E s t i m i z a t i o n F a s t e r , B e t t e r, S m a r t e r!"
Jeffrey D. Kelly Industrial Algorithms Limited - i n d u s t r i @ l g o r i t h m s Email: @.*** Phone: (647) 917-4675 (IMPL) Making Industrial AI (Algorithms & Integration) Real!
This email and any files transmitted with it are confidential, proprietary and intended solely for the individual or entity to whom they are addressed. If you have received this email in error please delete it immediately.
Yes, if you're interfacing the callback you'll need to use the latest header and potentially make some minor changes to your code.
It's probably easiest to see a diff of the changes I made to HiGHS.jl: https://github.com/jump-dev/HiGHS.jl/pull/281/files
HIGHS runs without raising any exception however it does not give the correct global solution for the MIP - this is another issue.
:+1: open an issue with a reproducible example?
Thank you - the problem is the void* cbdata equivalence in a Fortran data type structure.
This means that with the HIGHS 1.11.0 changes from 1.10.0, it is no longer interfaceable directly with Fortran without some more specific interface routine instead of the combined data structure.
I am not sure if it would be possible for the void* cbdata to be placed at the very end of the C data structure?
On Mon, Jun 9, 2025 at 4:03 PM Oscar Dowson @.***> wrote:
odow left a comment (ERGO-Code/HiGHS#2400) https://github.com/ERGO-Code/HiGHS/issues/2400#issuecomment-2956878365
Yes, if you're interfacing the callback you'll need to use the latest header and potentially make some minor changes to your code.
It's probably easiest to see a diff of the changes I made to HiGHS.jl: https://github.com/jump-dev/HiGHS.jl/pull/281/files
— Reply to this email directly, view it on GitHub https://github.com/ERGO-Code/HiGHS/issues/2400#issuecomment-2956878365, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALHONEHLCFJT5AUS6IJDD2T3CXR75AVCNFSM6AAAAAB627CHQOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSNJWHA3TQMZWGU . You are receiving this because you were mentioned.Message ID: @.***>
--
I M P L - " M a k i n g O p t i m i z a t i o n a n d E s t i m i z a t i o n F a s t e r , B e t t e r, S m a r t e r!"
Jeffrey D. Kelly Industrial Algorithms Limited - i n d u s t r i @ l g o r i t h m s Email: @.*** Phone: (647) 917-4675 (IMPL) Making Industrial AI (Algorithms & Integration) Real!
This email and any files transmitted with it are confidential, proprietary and intended solely for the individual or entity to whom they are addressed. If you have received this email in error please delete it immediately.
From #2404
Dear HIGHS;
Previously with HIGHS 1.10.0, it was possible to interface directly in Fortran integer-feasible solution callbacks and then to retrieve the integer-feasible-solution's mip_solution() 1D-array via the HighsCallbackDataOut data structure.
Unfortunately with HIGHS 1.11.0, this is no longer possible with the addition of the "void* cbdata" item.
It is also not possible to use Highs_getCallbackDataOutItem() as it also requires to interface to the HighsCallbackDataOut data structure.
In the C to Fortran interoperability standard there is a mapping between "void*" and "type(c_ptr)" when the data structure is defined with the bind(c) attribute but due to the dynamic allocation of mip_solution() (i.e., real (c_double), allocatable, dimension(:) :: mip_solution), bind(c) cannot be applied and hence the "type(c_ptr) :: cbdata" is not possible.
I am wondering if it would be possible in the future to define a direct way to retrieve the mip_solution() vector inside the HIGHS integer-feasible solution callback without using HighsCallbackDataOut?
All the best - Jeff