On 28Sep2018 20:12, Chris Green <cl at isbd.net> wrote:
>Peter Pearson <pkpearson at nowhere.invalid> wrote:
>> On Fri, 28 Sep 2018 15:01:41 +0100, Chris Green <cl at isbd.net> wrote:
>> > Chris Green <cl at isbd.net> wrote:
>> >> Brian Oney <brian.j.oney at googlemail.com> wrote:
>> >> > Could you please try another tool like `convert'? E.g.
>> >> >
>> >> > $ convert 102_PANA/P1020466.JPG test.png
>> >> >
>> >> > What does that say?
>> >> Well, after having returned home with the laptop where this was
>> >> failing and doing exactly the same thing again, it now works. However
>> >> it did take several seconds before the >>> prompt appeared.
>> >> The problem seems to be intermittent as I'm calling the function while
>> >> importing images from a camera SD card and, sometimes, the import
>> >> hangs but most times it works OK.
Can you separate the conversion from the copy? Copy the images off, run convert
against the copies? That would give you more info as to whether it was the copy
(implying an issue with the SD card as Peter suggests) or some pathologial
image data (eg spinning out convert).
Also, you can strace the hanging process; I'm a big fan of this for diagnostic
purposes. A "hanging" process will normally be either spinning (using lots of
CPU, or a mix of CPU and OS calls), or blocked (using no CPU at all while it
waits for a OS call to complete). If it is blocked doing a read() then you
immediately suspect the device from which the read is taking place.
WRT to the strace, find the pid with "ps" then:
strace -p pid-of-process
It is usually astonishingly helpful in telling you about the underlying
activity causing the problem.
Also, if the SD card is emitting errors these should show in the output of
dmesg. (OTOH if the SD cards internals are taking forever, perhaps doing
repeated _internal_ access to the data) then this may not be apparent.
Cameron Simpson <cs at cskk.id.au>