aaru-dps / Aaru

Aaru Data Preservation Suite
Other
493 stars 35 forks source link

Aaru crashes without an interactive shell to output to. #843

Closed maxz closed 5 months ago

maxz commented 5 months ago

Version

5.3.0

Commit hash

No response

Tested debug version?

Which operating systems have you used?

What is the architectural bit size you're using?

What processor are you using?

Device manufacturer

PLEXTOR (Irrelevant for this report.)

Device model

CD-R PX-W4012A (Irrelevant for this report.)

Bus the device uses to attach to the computer

USB cable or card reader manufacturer

JMicron Technology Corp. / JMicron USA Technology Corp. (Irrelevant for this report.)

USB cable or card reader model

JM20337 Hi-Speed USB to SATA & PATA Combo Bridge (Irrelevant for this report.)

What were you doing when it failed?

Description

I'm using Aaru as part of my dumping pipeline together with other programs like DiscImageCreator and Redumper. Therefore I'm calling it as a subprocess and as part of a bigger program, not manually in a shell.

The problem is that Aaru crashes unless it gets to write to the parent process' stdout. (e. g. when letting it write to another output stream or file) I'm allowing this right now so that I can verify the results of the other programs with Aaru, but I do not care about the output and would rather discard it instead of having it pollute the shell.

This is a minimal example to show the erratic behaviour. It happens when calling it as a subprocess from any language while denying access to the parent process' stdout.

#!/usr/bin/env python3                                                                              

from subprocess import DEVNULL, Popen

aaru_process = Popen(('/opt/aaru/aaru',
                      'media', 'dump',
                      '--format', 'Aaru Format',
                      '--verbose',
                      '--debug',
                      '/dev/sr0',
                      '/tmp/EXAMPLE'),
                     env={'DOTNET_SYSTEM_GLOBALIZATION_INVARIANT': '1'},
                     stdout=DEVNULL)

aaru_process.communicate()

If you remove the redirect of stdout (the last line in the call), it works as expected.

Exact command line used

DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=1 /opt/aaru/aaru media dump --format 'Aaru Format' --verbose --debug /dev/sr0 /tmp/EXAMPLE

Expected behavior

Aaru should operate normally, no matter whether the output stream is the standard output, an arbitrary output stream or a file.

Actual behavior

Aaru crashes when it is called without being passed the standard output stream from its parent process.

Output of command execution with debug output enabled

DEBUG (Dump-Media command): --cicm-xml=
DEBUG (Dump-Media command): --debug=True
DEBUG (Dump-Media command): --device=/dev/sr0
DEBUG (Dump-Media command): --encoding=
DEBUG (Dump-Media command): --first-pregap=False
DEBUG (Dump-Media command): --fix-offset=True
DEBUG (Dump-Media command): --force=False
DEBUG (Dump-Media command): --format=Aaru Format
DEBUG (Dump-Media command): --metadata=True
DEBUG (Dump-Media command): --options=
DEBUG (Dump-Media command): --output=/tmp/EXAMPLE
DEBUG (Dump-Media command): --persistent=False
DEBUG (Dump-Media command): --resume=True
DEBUG (Dump-Media command): --retry-passes=5
DEBUG (Dump-Media command): --skip=512
DEBUG (Dump-Media command): --stop-on-error=False
DEBUG (Dump-Media command): --trim=True
DEBUG (Dump-Media command): --verbose=True
DEBUG (Dump-Media command): --subchannel=any
DEBUG (Dump-Media command): --private=False
DEBUG (Dump-Media command): --fix-subchannel-position=True
DEBUG (Dump-Media command): --retry-subchannel=True
DEBUG (Dump-Media command): --fix-subchannel=False
DEBUG (Dump-Media command): --fix-subchannel-crc=False
DEBUG (Dump-Media command): --generate-subchannels=False
DEBUG (Dump-Media command): --skip-cdiready-hole=True
DEBUG (Dump-Media command): --eject=False
DEBUG (Dump-Media command): --max-blocks=64
DEBUG (Dump-Media command): --use-buffered-reads=True
DEBUG (Dump-Media command): --store-encrypted=True
DEBUG (Dump-Media command): --title-keys=True
DEBUG (Dump-Media command): Parsed options:
DEBUG (SCSI Device): INQUIRY took 0.4077 ms.
DEBUG (ATA Device): IDENTIFY PACKET DEVICE took 0.0063 ms.
DEBUG (SCSI Device): GET CONFIGURATION (Starting Feature Number: 264, Return Type: Single, Sense: False, Last Error: 0) took 0.2875 ms.
Unhandled exception: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation.
 ---> System.ArgumentOutOfRangeException: Count cannot be less than zero. (Parameter 'count')
   at System.String.Ctor(Char c, Int32 count)
   at Aaru.Progress.ClearCurrentConsoleLine() in /home/claunia/Development/Aaru/Aaru/Aaru/Progress.cs:line 85
   at Aaru.Progress.UpdateStatus(String text) in /home/claunia/Development/Aaru/Aaru/Aaru/Progress.cs:line 78
   at Aaru.Core.Devices.Dumping.Dump.Start() in /home/claunia/Development/Aaru/Aaru/Aaru.Core/Devices/Dumping/Dump.cs:line 220
   at Aaru.Commands.Media.DumpMediaCommand.Invoke(Boolean debug, Boolean verbose, String cicmXml, String devicePath, Boolean resume, String encoding, Boolean firstPregap, Boolean fixOffset, Boolean force, Boolean metadata, Boolean trim, String outputPath, String options, Boolean persistent, UInt16 retryPasses, UInt32 skip, Byte speed, Boolean stopOnError, String format, String subchannel, Boolean private, Boolean fixSubchannelPosition, Boolean retrySubchannel, Boolean fixSubchannel, Boolean fixSubchannelCrc, Boolean generateSubchannels, Boolean skipCdiReadyHole, Boolean eject, UInt32 maxBlocks, Boolean useBufferedReads, Boolean storeEncrypted, Boolean titleKeys) in /home/claunia/Development/Aaru/Aaru/Aaru/Commands/Media/Dump.cs:line 679
   --- End of inner exception stack trace ---
   at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor, Boolean wrapExceptions)
   at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   at System.Reflection.MethodBase.Invoke(Object obj, Object[] parameters)
   at System.CommandLine.Invocation.ModelBindingCommandHandler.InvokeAsync(InvocationContext context)
   at System.CommandLine.Invocation.InvocationPipeline.<>c__DisplayClass4_0.<<BuildInvocationChain>b__0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c.<<UseParseErrorReporting>b__19_0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass14_0.<<UseHelp>b__0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass22_0.<<UseVersionOption>b__0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass21_0.<<UseTypoCorrections>b__0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c.<<UseSuggestDirective>b__20_0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c.<<UseParseDirective>b__18_0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c.<<UseDebugDirective>b__10_0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c.<<RegisterWithDotnetSuggest>b__9_0>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.CommandLine.Builder.CommandLineBuilderExtensions.<>c__DisplayClass12_0.<<UseExceptionHandler>b__0>d.MoveNext()

Media details

The behaviour is independent of any concrete medium.

claunia commented 5 months ago

Please try -devel or -alpha9. We have changed the console handler and the behaviour may be completely different.

maxz commented 5 months ago

I will try it and report back. Thanks.

maxz commented 5 months ago

It works fine with aaru-6.0.0-alpha9_linux_amd64-dbg / aaru 6.0.0~alpha9+e10c237e, both with the example program and with my actual non-Python program.

You probably do not intend to port the changes back to version 5.3, so I will close the issue.

claunia commented 5 months ago

Afraid not, it's not "just a change", it's a whole architectural change (that introduced a hundred bugs that are not all fixed yet :D)