Describe the bug
I investigated a reproducible crash of MaxQuant 2.8.0 on Linux and I would like to report the problem chain as clearly as possible.
It appears that when MaxQuant launches parallel search subprocesses (for example MSMS search tasks), the generated command line contains an unintended double space between some arguments.
Example pattern:
dotnet ./MaxQuantTask.dll proc MSMS_first_search 0 MSMS_first_search (01/36) Process 73 0 search_path ...
There are two spaces before "(01/36)".
On Linux, this seems to result in an extra empty string argument being passed to the child process. In other words, the child process receives an argv array that contains an unexpected "" entry.
Because of this extra empty argument, all following argv positions are shifted by one. Then MaxQuantTask interprets the wrong argument at each position. As a result, a value that should be parsed as an integer may actually be a path string, or a path parameter may be read from the wrong position.
This eventually causes a crash such as System.FormatException when the child task tries to parse an argument at the expected numeric position.
So the problem chain appears to be:
double space in generated command
-> extra empty argument in child argv on Linux
-> argv positions shifted
-> wrong parameter read at fixed index
-> System.FormatException / subprocess crash
-> missing .res output
-> later steps fail because search result files are not found
To Reproduce
- Run MaxQuant 2.8.0 on Linux.
- Start a job with multiple parallel MSMS search subprocesses.
- Observe the spawned task command line in logs / process tracing.
- In affected cases, the command line contains a double space before the progress descriptor, e.g. before "(01/36)".
- The subprocess then crashes with parameter parsing errors.
Observed behavior
- Parallel search subprocesses crash.
- Some tasks terminate with System.FormatException.
- No valid .res output is produced for the failed search task.
- Later workflow steps fail because expected search result files are missing.
Expected behavior
MaxQuant should spawn child processes with a correctly formatted argument list, without unintended empty arguments, and Linux child processes should receive the same logical argument sequence that MaxQuant intended.
Additional analysis
I also found that not every subprocess should be "fixed" in the same way.
For example, a sequential task such as Combining_apl_files_for_first_search may contain the word "search" in its name, but its command line itself is valid and does not seem to suffer from the same double-space issue.
So a broad workaround based only on matching the substring "search" can break healthy commands by modifying arguments that were already correct.
In addition, simply removing the empty argument is not always sufficient, because the progress description itself may still need to be handled correctly. If only the empty argument is removed without restoring the intended argument structure, later parameters can still remain misaligned.
Why I think the bug is in this area
From debugging, the crash does not seem to come from the biological input data itself. The failure pattern is consistent with argument misalignment in spawned subprocesses:
- child process receives an unexpected empty argv element
- fixed-position argument parsing then reads the wrong value
- integer parsing fails on a path-like string
Possible fix
I suspect the safest fix would be to prevent the extra double space from being generated when building the child process command, or to build the subprocess arguments using an argument array / argument list approach instead of relying on string concatenation.
Environment
- MaxQuant version: 2.8.0
- OS: Linux
- Runtime: .NET on Linux
- Execution mode: command line / MaxQuantCmd
If helpful, I can also provide logs and a more detailed example of the shifted argv sequence.
Describe the bug
I investigated a reproducible crash of MaxQuant 2.8.0 on Linux and I would like to report the problem chain as clearly as possible.
It appears that when MaxQuant launches parallel search subprocesses (for example MSMS search tasks), the generated command line contains an unintended double space between some arguments.
Example pattern:
dotnet ./MaxQuantTask.dll proc MSMS_first_search 0 MSMS_first_search (01/36) Process 73 0 search_path ...
There are two spaces before "(01/36)".
On Linux, this seems to result in an extra empty string argument being passed to the child process. In other words, the child process receives an argv array that contains an unexpected "" entry.
Because of this extra empty argument, all following argv positions are shifted by one. Then MaxQuantTask interprets the wrong argument at each position. As a result, a value that should be parsed as an integer may actually be a path string, or a path parameter may be read from the wrong position.
This eventually causes a crash such as System.FormatException when the child task tries to parse an argument at the expected numeric position.
So the problem chain appears to be:
double space in generated command
-> extra empty argument in child argv on Linux
-> argv positions shifted
-> wrong parameter read at fixed index
-> System.FormatException / subprocess crash
-> missing .res output
-> later steps fail because search result files are not found
To Reproduce
Observed behavior
Expected behavior
MaxQuant should spawn child processes with a correctly formatted argument list, without unintended empty arguments, and Linux child processes should receive the same logical argument sequence that MaxQuant intended.
Additional analysis
I also found that not every subprocess should be "fixed" in the same way.
For example, a sequential task such as Combining_apl_files_for_first_search may contain the word "search" in its name, but its command line itself is valid and does not seem to suffer from the same double-space issue.
So a broad workaround based only on matching the substring "search" can break healthy commands by modifying arguments that were already correct.
In addition, simply removing the empty argument is not always sufficient, because the progress description itself may still need to be handled correctly. If only the empty argument is removed without restoring the intended argument structure, later parameters can still remain misaligned.
Why I think the bug is in this area
From debugging, the crash does not seem to come from the biological input data itself. The failure pattern is consistent with argument misalignment in spawned subprocesses:
Possible fix
I suspect the safest fix would be to prevent the extra double space from being generated when building the child process command, or to build the subprocess arguments using an argument array / argument list approach instead of relying on string concatenation.
Environment
If helpful, I can also provide logs and a more detailed example of the shifted argv sequence.