Linux: Received image are sometimes all black

[Wasseranomalie]

• [X] I have searched open and closed issues for duplicates

---

Bug description

A received image shows only black instead of the true image. Unfortunately I don't have steps to reproduce.

Edit: My Linux-instance received and shows the image without problems.

Screenshots

Desktop: Android: This should be the original image:

Platform info

Signal version: 1.16.0

Operating System: Windows 10

Linked device version: 4.25.10 (Android)

Link to debug log

https://debuglogs.org/35c3a4cc8d1cda9631883b394b3e5dbd11bf6b974a3cdfd2815d6e61b938fb1d The attachment-download starts at 2018-09-13T07:41:38.893Z

[fitdev]

I have a similar issue, except it says Image has failed to load. Same version, and also on Windows 10.

[scottnonnenberg-signal]

What do you see if you download the attachment to disk and then try to view it?

[Wasseranomalie]

It is still just black.

This is the image saved on disk:

[scottnonnenberg-signal]

Is the third attached image in the original post the original message before it was sent by Signal Desktop? The app does some processing with JPEG attachments to ensure that they are rotated properly - it's likely a problem in that computation, so I want to be sure I get the file that hasn't been processed at all by Signal Desktop.

[Wasseranomalie]

It is the original image sent by a colleague of mine. But it has been sent by Signal Android. I just tried to verify if it is also black on my second Windows 10-instance, but there the image looks normal...

[scottnonnenberg-signal]

Can you also double-check the Signal Desktop versions on those two windows computers?

[Wasseranomalie]

Yes, both have version 1.16.0 installed

[fitdev]

In my case, it says image failed to load:

When I click on the download button and enter file name in the Save File dialog nothing gets saved - no file is written. The image is supposed to be a jpeg.

[scottnonnenberg-signal]

@fitdev Please consider providing the original image you're trying to send. A local repro of this is key to use being able to fix it. You can always send it to me directly, or to support@signal.org.

[fitdev]

@scottnonnenberg-signal Sorry it was not clear. I was trying to receive an image, not send it. And since it "failed to load", I do not have it. I am certain it started with 1.16

[scottnonnenberg-signal]

@fitdev I'm asking you to reach out to the original sender to get it sent to you as a zip file. :0)

[megansquire]

I had this problem when sending images using Signal desktop on an older Mac desktop machine (circa 2009). The mac was running os version 10.11.6 (El Cap). Signal Desktop was version 1.15.5. It happened with JPG images, but not PNG. Both myself (the sender) and the viewer (recipient) both saw only black images.

[scottnonnenberg-signal]

@megansquire Any chance you could provide the image both before and after processing (black and original?). Also, what happens if you send that same image on recent builds?

[protist]

FWIW I'm having the same problem on Linux, both systems running the same distro and Signal version. The image displayed fine on Android and one of the desktops. However, the other displayed a black image. Hence, I don't think this issue is related to the image itself. I've been having connectivity problems with the latter system, so presumably the download was interrupted, and Signal is failing to detect the corrupt image and/or redownload it.

[scottnonnenberg-signal]

@protist Hm. Might be interesting to download that file on one desktop that downloaded it properly and on another desktop that didn't, and see what the diff is.

[protist]

@scottnonnenberg-signal I've sent you an email with the attachments as, erm, attachments.

[scottnonnenberg-signal]

Okay, so I've discovered some things. First, the all-black image is far smaller:

 57K Mar 12 17:23 signal-attachment-2020-03-03-085407.broken.jpeg
1.5M Mar 12 17:23 signal-attachment-2020-03-03-085407.working.jpeg

Second, it is all zeros after the preamble:

Quite odd. To review, the image downloaded fine on Signal Android and a Signal Desktop. But on another machine, same Signal Desktop version but shakey internet connection, this happened. It would be much appreciated if you could grab a debug log (and the files just like this time) when this next happens - it's not often in the modern world that network connectivity causes corruption like this, instead of outright errors. We'd certainly like to do our part to avoid it.

[protist]

It's happened a few times again since then. I've emailed you another working/failing image, along with the debug log. We've actually had our internet fixed before this new failure, so perhaps the issue is unrelated to network connectivity?

The debug log is quite a bit later than the message, so I suspect Signal was closed at the time of the message, and I only launched it later.

FWIW I also use a VPN. This briefly interrupts connectivity after resume from suspend, so alternatively this may be related as well. But yes, I'd expect an error rather than corruption of the file.

[protist]

From the sounds of it (as per our email conversation @scottnonnenberg-signal), there's not too much informative in the logs. However, I just had this issue again today. I no longer have network connectivity issues, and this was nothing to do with a delayed message. I had a super-stable connection, had resumed from suspend an hour ago, but this image was still black on my system.

[scottnonnenberg-signal]

@protist Given that we've never seen this before, maybe the right thing to do is look into your hardware? Maybe you could find some tests to see if network data sometimes gets garbled?

[protist]

@scottnonnenberg-signal I'm not really sure what kind of tests I could run. I can't recall any checksum ever come back as incorrect. (I just checked, and I do 20 checksum tests per day, from package manager updates.)

[protist]

I actually had another error again on the same (home) computer. I've also since brought my work computer home because of COVID-19. It's now on the same network. However, I still haven't had any errors on the work computer, which makes me think it's not necessarily a network issue but something corrupt on my home computer.

[scottnonnenberg-signal]

@protist Well, at this point we're just looking for more information from you. How many of your incoming images show properly, and how many show up as black? Is there any pattern to it?

[protist]

@scottnonnenberg-signal There's no obvious pattern. I looked through my last 50 incoming images, and two failed.

[scottnonnenberg-signal]

What about file format? Has it ever happened for a GIF? Or does it always happen with JPG files, for example?

[protist]

@scottnonnenberg-signal Took a while for this to happen again. It was a JPEG again this time. I don't think I've ever had it with a GIF, nor a PNG, but I might be mistaken.

[scottnonnenberg-signal]

For JPEG images specifically, Signal Desktop will verify that they are of the correct rotation, and if not, do some local processing to do that rotation. I wonder if this happens for every image your Desktop instance tries to rotate, or just some of them. That's something worth investigating.

[protist]

That sounds potentially promising. I'm happy to do whatever troubleshooting you might suggest.

[scottnonnenberg-signal]

Here's more information on JPEG rotation metadata. The key would be to get your hands on some files with that metadata (maybe you have a camera/phone that does it), see if it makes a difference: https://jdhao.github.io/2019/07/31/image_rotation_exif_info/

[protist]

@scottnonnenberg-signal But given I have two identical systems, and it works inconsistently on each, does that suggest it's not as reproducible at exif rotation would suggest?

[scottnonnenberg-signal]

@protist My creeping suspicion is that it actually has to do with graphics hardware; that's my theory for why the offscreen image rotation logic would behave so problematically on your system. Though the machines are identical, over time wear can cause hardware to develop idiosyncrasies.

Maybe you could try a --disable-gpu command-line argument to launch Signal Desktop after you get an image that repros this successfully? Maybe disabling the graphics hardware will prevent the repro?

[protist]

That's actually a good point @scottnonnenberg-signal, and one that I skimmed over a bit in my explanations above. Both of my systems are running the same Linux distro, but they are different in hardware. I hadn't thought that GPU/hardware might be relevant here. In retrospect, I think that I've only seen issues in the system running Nvidia (proprietary) drivers. The other is Intel integrated.

I just tried signal-desktop --disable-gpu, scrolling up to one of the previously-blank images, but it is still totally black. But are you suggesting that --disable-gpu might be able to fix the image after it has already failed? Were you implying that the GPU might break on-screen display, or pre-processing (if only one)? I thought the latter, because the downloaded file was also broken, but then this would imply --disable-gpu wouldn't be able to fix an already-broken image.

[scottnonnenberg-signal]

No, I mean that it would fix the rotation processing on receipt when you find a file that consistently repros. But I suppose that's the trick, right? Even when you get one of these files, resending it so that Desktop needs to reprocess it doesn't necessarily result in the black? Or have you tried those kinds of tests?

[protist]

@scottnonnenberg-signal I hadn't actually thought to test if it's reproducible. I just tested using the following.

1) Identify the failed image from a week ago (on my Nvidia home computer) 2) Download the working equivalent (on my work computer) 3) Resend this version to myself from this computer 4) Observe the newly-arrived file on my Nvidia home computer

For 4., I tested both with --disable-gpu and vanilla signal, but the attachment worked fine both times.

[scottnonnenberg-signal]

Okay, so it is not consistently reproducible even with a file where it's known to have happened in the past. Unfortunate. I did look at the code, and with our decryption and MAC validation, all corruption pretty much has to happen after that - during rotation or the save to disk.

[protist]

Aha! I think I have a situation that is fairly reproducible.

1. Have signal-desktop open
2. Switch to another TTY with another user logged in. In my case, it was also running a desktop environment (KDE), but without a window display manager, i.e. originally launched with startx.
3. Send a picture attachment to myself
4. Switch back to the original TTY

I just tested, and 3/4 times it failed with a black image. The fourth time it partially worked, but the image was visually corrupted. While testing, I stayed in the original TTY and received an image perfectly fine. Let me know if you can reproduce it @scottnonnenberg-signal, but if not, I'm happy to privately send you the corrupted fourth image, if that might be useful.

[scottnonnenberg-signal]

Hm. Can you tell me more about that configuration in item 2? No window manager but under KDE? Is it that your other TTY doesn't have access to visual compositing when inactive, which means that canvas/screenshot-based resizing/rotating would fail?

[protist]

Ack, sorry @scottnonnenberg-signal, I meant without a display manager, not window manager. i.e. instead of auto-launching SDDM when switching to TTY2, I manually log in at the console, then start a session with startx. I'm not sure how to test whether visual compositing works. Is there a test command that I can schedule while TTY1 is in the background?

[scottnonnenberg-signal]

I've got nothing for you, unfortunately. Maybe consider using Signal Desktop in a less convoluted configuration?

[protist]

@scottnonnenberg-signal To be clear, this issue doesn't only occur when in another TTY. This is just a specific situation where I could replicate the bug easily and reproducibly, and hence you might be able to replicate on your own system for debugging. It certainly occurs in many other situations.

[mieko]

In case this helps in the future: this GIF, when sent from Signal-Desktop v1.39.6 on macOS 11.1 results in a blank (not black) square when received on Signal-iOS, and shows a black image when tapped.

Viewing the conversation as the sender from Signal-Android, it is rendered correctly.

[scottnonnenberg-signal]

@mieko Thanks for a laugh. :0) I've reported that bug to the iOS team, since it also happens if you send it from Android.

[Dr-Cool]

Same problem here. In my case, Signal Desktop for Linux version 5.3.0 running on a Lenovo Ideapad Y910 (with a NVidia GPU) under system Ubuntu 20.04.2. All problem images are jpeg, but not all jpeg images are blackened out. They appear correctly on my Android Signal app. About 1 in 4 images are blackened out, from different senders, and some images are part of shared news links (the linked news image appears correctly on the Android app). Downloading creates a jpeg file that is also blackened out, but has sensible information about image size. All permissions were given to the app.

[scottnonnenberg-signal]

@Dr-Cool Please consider providing some of the jpeg images in question - you can send them to me directly, or to support.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[protist]

Still a problem, stale bot. I had this issue about a week ago.

[EvanHahn-Signal]

Sorry to hear you're still running into it. We still haven't been able to reproduce the problem. Detailed reproduction steps would be beneficial, including the images that are being sent.

[protist]

Thanks @EvanHahn-Signal for the response, but I think there have been two or three images posted here already. In any case, I don't think it's the specific image that is the problem, as I posted above in my detailed reproduction steps.

[Dr-Cool]

Want to let you know that I stopped experiencing this error for some time now.

[protist]

@EvanHahn-Signal FWIW I tested my previously-posted "detailed reproduction steps" as requested, and I can still reproduce this issue in signal 5.18.1