General > General Technical Chat
Server Error Reports
Ed.Kloonk:
--- Quote from: RoGeorge on March 19, 2023, 07:59:42 pm ---
--- Quote from: Nominal Animal on March 19, 2023, 07:11:23 pm ---
--- Quote from: RoGeorge on March 19, 2023, 06:48:49 pm ---No matter were I click or what I refresh, I see a brown+black cat under some LED lights, just that the picture is wrongly rotated with +90.
--- End quote ---
Open the large image into a new tab, then press Shift while clicking the Refresh button. This causes a force-reload. Just clicking Refresh reloads the image from your local cache.
--- End quote ---
Might be something else, now it's the wrong picture to my FF, too, with or without refresh, with or without shift click.
--- End quote ---
Might be time to vacuum the cat fur out of the site server.
beanflying:
All of this is nothing to do with the server or SMF (proper) and everything to do with a few Image handling addons that got installed several years ago which broke some of the code when installed on top of each other.
Nominal Animal:
--- Quote from: RoGeorge on March 19, 2023, 07:59:42 pm ---
--- Quote from: Nominal Animal on March 19, 2023, 07:11:23 pm ---
--- Quote from: RoGeorge on March 19, 2023, 06:48:49 pm ---No matter were I click or what I refresh, I see a brown+black cat under some LED lights, just that the picture is wrongly rotated with +90.
--- End quote ---
Open the large image into a new tab, then press Shift while clicking the Refresh button. This causes a force-reload. Just clicking Refresh reloads the image from your local cache.
--- End quote ---
Might be something else, now it's the wrong picture to my FF, too, with or without refresh, with or without shift click.
--- End quote ---
Nope, the exact same thing.
When you load anything over http or https protocol, the server can specify an expiry time, telling the browser how long the resource should stay unchanged. For the above file, the forum serves such an Expires header a year in the future, and also a Last-Modified header describing when the resource was last modified.
When you click Reload/Refresh, the browser only checks its own local cache; at most, it can send a HEAD request, which provides only the headers and none of the file data.
Thing is, the headers did not change. They still reflect the original image file, claiming MIME type image/jpeg and file name IMG_20230316_110455672_HDR.jpg. The actual data, however, is of image/png type, and not a JPEG file at all.
So, the browser just saw its cached data still valid, and re-showed the cached image. When you do a force-reload, Shift+Reload, you tell the browser to skip the cache and header check, and do a GET request from the source (or proxy), which provided the new content.
Depending on your browser cache settings, when you closed that Firefox session (last open Firefox window), it discarded that cached image. So, when you next opened Firefox and tried to look at the image, Firefox dutifully did a GET request because it didn't have it cached anymore, and bang, you see the replaced image.
You can trust me on this, because I can tell you exactly what is happening and how, even though I have never had access to an SMF implementation (source code). It runs on Nginx, and the image/attachment provider part is written in PHP – the headers I receive with the above URL tell me that. The image/attachment metadata in the database is not corrupted –– it still exists for both the old image and the new image, only the old image binary data was replaced with the new image binary data; you can verify that by looking at the headers of both the old (now switched) image, and the image that replaced it. I am not sure whether the binary data is stored in the database or in binary files, so I cannot tell for sure whether it is the data itself or just the reference to the data that got changed for the old image, but I'd bet it is the reference; and the root bug is in the database query updating the binary data reference to the attachment after the upload completes. Instead of updating just the one entry, it ends up sometimes updating the reference also for an older image. Again, image metadata (format, file name) are not similarly confused, so this must be a separate update.
(I do have a decade of commercial development experience in this stuff; I did it for years before switching back to academia, but still have kept up with the (rather small) changes since then.)
gnif:
Please be aware that I am performing some general system maintenance and there may be minor interruptions during this.
Edit: Work has been completed.
gnif:
--- Quote from: Nominal Animal on March 20, 2023, 07:19:57 am ---
--- Quote from: RoGeorge on March 19, 2023, 07:59:42 pm ---
--- Quote from: Nominal Animal on March 19, 2023, 07:11:23 pm ---
--- Quote from: RoGeorge on March 19, 2023, 06:48:49 pm ---No matter were I click or what I refresh, I see a brown+black cat under some LED lights, just that the picture is wrongly rotated with +90.
--- End quote ---
Open the large image into a new tab, then press Shift while clicking the Refresh button. This causes a force-reload. Just clicking Refresh reloads the image from your local cache.
--- End quote ---
Might be something else, now it's the wrong picture to my FF, too, with or without refresh, with or without shift click.
--- End quote ---
Nope, the exact same thing.
When you load anything over http or https protocol, the server can specify an expiry time, telling the browser how long the resource should stay unchanged. For the above file, the forum serves such an Expires header a year in the future, and also a Last-Modified header describing when the resource was last modified.
When you click Reload/Refresh, the browser only checks its own local cache; at most, it can send a HEAD request, which provides only the headers and none of the file data.
Thing is, the headers did not change. They still reflect the original image file, claiming MIME type image/jpeg and file name IMG_20230316_110455672_HDR.jpg. The actual data, however, is of image/png type, and not a JPEG file at all.
So, the browser just saw its cached data still valid, and re-showed the cached image. When you do a force-reload, Shift+Reload, you tell the browser to skip the cache and header check, and do a GET request from the source (or proxy), which provided the new content.
Depending on your browser cache settings, when you closed that Firefox session (last open Firefox window), it discarded that cached image. So, when you next opened Firefox and tried to look at the image, Firefox dutifully did a GET request because it didn't have it cached anymore, and bang, you see the replaced image.
You can trust me on this, because I can tell you exactly what is happening and how, even though I have never had access to an SMF implementation (source code). It runs on Nginx, and the image/attachment provider part is written in PHP – the headers I receive with the above URL tell me that. The image/attachment metadata in the database is not corrupted –– it still exists for both the old image and the new image, only the old image binary data was replaced with the new image binary data; you can verify that by looking at the headers of both the old (now switched) image, and the image that replaced it. I am not sure whether the binary data is stored in the database or in binary files, so I cannot tell for sure whether it is the data itself or just the reference to the data that got changed for the old image, but I'd bet it is the reference; and the root bug is in the database query updating the binary data reference to the attachment after the upload completes. Instead of updating just the one entry, it ends up sometimes updating the reference also for an older image. Again, image metadata (format, file name) are not similarly confused, so this must be a separate update.
(I do have a decade of commercial development experience in this stuff; I did it for years before switching back to academia, but still have kept up with the (rather small) changes since then.)
--- End quote ---
This issue was thought to be fixed, I have just checked on disk and I can confirm that the file on disk contains the incorrect data. The file is indeed a PNG of a schematic, but the database thinks it is a JPEG.
The last time we had this issue it was identified to be a bug with the clustering filesystem (GlusterFS) which was causing inodes to be duplicated, upgrading the software resolved this and I do not see any duplicated inodes reported this time either.
If anyone figures out a reliable way to reproduce the fault and can provide step by step instructions so that I can dig deeper it would be greatly appreciated.
Edit: I have also contacted the OP of the message to try to obtain an exact copy of the image that it should be for further diagnostics
Edit2: It gets even stranger... I found the post the replaced image comes from, and it's even from the same user.
https://www.eevblog.com/forum/beginners/resistor-y-junction-calculations/msg4764878/#msg4764878
Edit3: Even stranger again... I pulled the two files from the server, they are the identical image, but they are different on disk. One has been altered/reprocessed? Starting to suspect a buggy image optimisation plugin or something.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version