Respect verbose=false in print_infeas_or_unbnd_message - #55
Open
ramakrishnap-nv wants to merge 1 commit into
Open
Respect verbose=false in print_infeas_or_unbnd_message#55ramakrishnap-nv wants to merge 1 commit into
ramakrishnap-nv wants to merge 1 commit into
Conversation
run_presolver() gates every other console message behind stgs->verbose (print_start_message, print_end_message), but calls print_infeas_or_unbnd_message() unconditionally when the problem is detected infeasible or unbounded. A caller that sets verbose = false to keep PSLP silent still gets "PSLP declares problem as infeasible." printed directly to stdout for exactly that case. Found while embedding PSLP in cuOpt's Java bindings (github.com/NVIDIA/cuopt): the caller already sets verbose = false, but this one unconditional printf writes directly to the process's native stdout stream, which corrupts tooling that intercepts stdout for its own purposes -- in our case, Maven Surefire's forked-JVM communication protocol. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
ramakrishnap-nv
added a commit
to NVIDIA/cuopt
that referenced
this pull request
Aug 28, 2026
Root-caused the residual Corrupted channel failures still hitting java-static-test after the NativeLogSink fix: PSLP v0.0.11's run_presolver() gates every other console message behind stgs->verbose (print_start_message, print_end_message), but calls print_infeas_or_unbnd_message() unconditionally when it detects the problem is infeasible or unbounded. cuOpt already sets verbose = false when calling PSLP (third_party_presolve.cpp), specifically to keep it silent, so this one line slips through despite that and writes straight to the process's native stdout -- bypassing System.out exactly like the raw write NativeLogSink was built to intercept, and corrupting Surefire's forked-JVM protocol the same way. The infeasible/unbounded status itself is unaffected: it already flows back to the caller through run_presolver()'s typed return value, not by parsing this printed text, so cuOpt's own (properly routed) status reporting is unchanged. Filed and fixed upstream: dance858/PSLP#55. Until a release containing it is available, patch the vendored v0.0.11 source at fetch time via a new PATCH_COMMAND on PSLP's FetchContent_Declare. Verified locally: rebuilt libcuopt_static + the JNI layer with the patch applied (confirmed via the fetched source) and ran the full Java suite, including ProblemIntegrationTest's infeasible-solve case which is what triggers this code path, 50 times in a loop. Every run passed with zero "Corrupted channel" occurrences (previously this reproduced on the very first attempt). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
ramakrishnap-nv
added a commit
to NVIDIA/cuopt
that referenced
this pull request
Aug 28, 2026
Root-caused the residual Corrupted channel failures still hitting java-static-test after the NativeLogSink fix: PSLP v0.0.11's run_presolver() gates every other console message behind stgs->verbose (print_start_message, print_end_message), but calls print_infeas_or_unbnd_message() unconditionally when it detects the problem is infeasible or unbounded. cuOpt already sets verbose = false when calling PSLP (third_party_presolve.cpp), specifically to keep it silent, so this one line slips through despite that and writes straight to the process's native stdout -- bypassing System.out exactly like the raw write NativeLogSink was built to intercept, and corrupting Surefire's forked-JVM protocol the same way. The infeasible/unbounded status itself is unaffected: it already flows back to the caller through run_presolver()'s typed return value, not by parsing this printed text, so cuOpt's own (properly routed) status reporting is unchanged. Filed and fixed upstream: dance858/PSLP#55. Until a release containing it is available, patch the vendored v0.0.11 source at fetch time via a new PATCH_COMMAND on PSLP's FetchContent_Declare. Verified locally: rebuilt libcuopt_static + the JNI layer with the patch applied (confirmed via the fetched source) and ran the full Java suite, including ProblemIntegrationTest's infeasible-solve case which is what triggers this code path, 50 times in a loop. Every run passed with zero "Corrupted channel" occurrences (previously this reproduced on the very first attempt). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
4 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
run_presolver()gates every other console message behindstgs->verbose(print_start_message,print_end_message), but callsprint_infeas_or_unbnd_message()unconditionally when the problem is detected infeasible or unbounded:A caller that sets
verbose = falseto keep PSLP silent still getsPSLP declares problem as infeasible.(or the unbounded variant) printed directly to stdout for exactly that one case.Why this matters
Found while embedding PSLP in cuOpt's Java bindings: the caller there already sets
verbose = false, but this one unconditionalprintfwrites directly to the process's native stdout stream. In a JVM host, that bypassesSystem.outand can corrupt tooling that intercepts stdout for its own purposes -- in our case, Maven Surefire's forked-JVM communication protocol, which uses stdout as its own IPC channel and reports a false "VM crash" when an unexpected raw write lands mid-frame.Fix
Gate the call the same way the surrounding code already gates the other two messages in this function: