Skip to content

Respect verbose=false in print_infeas_or_unbnd_message - #55

Open
ramakrishnap-nv wants to merge 1 commit into
dance858:mainfrom
ramakrishnap-nv:fix-infeasible-message-ignores-verbose
Open

Respect verbose=false in print_infeas_or_unbnd_message#55
ramakrishnap-nv wants to merge 1 commit into
dance858:mainfrom
ramakrishnap-nv:fix-infeasible-message-ignores-verbose

Conversation

@ramakrishnap-nv

@ramakrishnap-nv ramakrishnap-nv commented Aug 28, 2026

Copy link
Copy Markdown

Summary

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:

if (status != UNCHANGED)
{
    // problem detected to be infeasible or unbounded
    print_infeas_or_unbnd_message(status);
    return status;
}

A caller that sets verbose = false to keep PSLP silent still gets PSLP 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 unconditional printf writes directly to the process's native stdout stream. In a JVM host, that bypasses System.out and 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:

if (status != UNCHANGED)
{
    // problem detected to be infeasible or unbounded
    if (stgs->verbose)
    {
        print_infeas_or_unbnd_message(status);
    }
    return status;
}

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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant