[1.1.104] Crash on --dump-icon-sprites (linux)

[KeepResearchinSpoons]

seen from at least v1.1.100 (also v1.1.104), game crashes on using `./bin/x64/factorio --dump-icon-sprites`
kinda works for some(?) items, but then crashes up with "pls report".
(( side note, would have been NICE if it dumped icons under `./script-output/icons/all-the-folders-go-HERE` instead of `./script-output/all-the-folders-go-HERE` but that is purely taste preference ))

the setup has 25 tiny mods, think FNEI, Train_Control_Signals, Jetpack, PickerBeltTools... but that is probably irrelevant, since same have also be observed with other mod groups.
specs are x11, mesa, kde, not sure if relevant either.

the log tail (v104) is

Code: Select all

   3.524 Factorio initialised
   4.633 Error CrashHandler.cpp:639: Received SIGSEGV
Factorio crashed. Generating symbolized stacktrace, please wait ...
/tmp/factorio-build-MzGUjo/src/Util/Logger.cpp (336): Logger::writeStacktrace(FileWriteStream*, StackTraceInfo*)
/tmp/factorio-build-MzGUjo/src/Util/Logger.cpp (346): Logger::logStacktrace(StackTraceInfo*)
/tmp/factorio-build-MzGUjo/src/Util/CrashHandler.cpp (188): CrashHandler::writeStackTrace(CrashHandler::CrashReason)
/tmp/factorio-build-MzGUjo/src/Util/CrashHandler.cpp (642): CrashHandler::commonSignalHandler(int)
/tmp/factorio-build-MzGUjo/src/Util/CrashHandler.cpp (648): CrashHandler::SignalHandler(int)
0x7f8d1e44251f
/tmp/factorio-build-MzGUjo/src/Graphics/DrawCommandBatch.cpp (599): DrawCommandBatch::drawSpriteFromTiledTexture(BlendMode, SamplingMode, TiledVideoBitmap const*, float, float, float, float, Color32, float, float, float, float, float, float, float, DrawingFlags, GraphicsEffect)
/tmp/factorio-build-MzGUjo/src/Graphics/DrawCommandBatch.hpp (94): DrawCommandBatch::drawSprite(BlendMode, SamplingMode, VideoBitmap const*, float, float, float, float, Color, float, float, float, float, float, float, float, DrawingFlags, SpriteEffectData const&, GraphicsEffect)
/tmp/factorio-build-MzGUjo/src/Graphics/ImageDrawOrder.cpp (116): ImageDrawOrder::render() const
/tmp/factorio-build-MzGUjo/src/Graphics/DrawQueue.cpp (2156): DrawQueue::renderOthers() const
/tmp/factorio-build-MzGUjo/src/Graphics/ScreenshotRequest.cpp (150): RenderIconsRequest::draw(DrawQueue&, Sprite const&, Filesystem::Path)
/tmp/factorio-build-MzGUjo/src/Graphics/ScreenshotRequest.cpp (111): operator()<PrototypeList<EquipmentPrototype> >
/tmp/factorio-build-MzGUjo/src/Util/MplVector.hpp (10): forEach<RenderIconsRequest::renderIcons() const::<lambda(auto:135)> >
/tmp/factorio-build-MzGUjo/src/Graphics/ScreenshotRequest.cpp (101): RenderIconsRequest::renderIcons() const [clone .constprop.0]
/tmp/factorio-build-MzGUjo/src/Main.cpp (941): main
../sysdeps/nptl/libc_start_call_main.h (58): __libc_start_call_main
../csu/libc-start.c (392): __libc_start_main_impl
0x783342
0xffffffffffffffff
Stack trace logging done
   4.803 Error Util.cpp:100: Unexpected error occurred. If you're running the latest version of the game you can help us solve the problem by posting the contents of the log file on the Factorio forums.

have fun with the bug-hunting!
( me available for other steps, if necessary )

[Bilka]

Cannot reproduce with the provided information. I'm on x11, proprietary nvidia driver, kde.

It may be helpful if you provide the full log because it contains information on the used graphics settings.

[KeepResearchinSpoons]

I also went to backups to confirm the same on 1.1.80
well, the difference really seems to only in video drivers? using the on-the-chip graphics on this box.

here's logs for vanilla 104 and vanilla 80 (actually verbose huh)

factorio-current.v1-1-104.log

(6.96 KiB) Downloaded 15 times

factorio-current.v1-1-80.log

(8.27 KiB) Downloaded 10 times

hope this helps...

Edit:

okay. now it goes into stranger things land.
clean v104 (from the site) plays the music (with no screen gui, huh) but actually succeeds with no crash.

with predictable log

Code: Select all

   0.118 Initialised OpenGL:[0] AMD Radeon Graphics (renoir, LLVM 15.0.7, DRM 3.54, 6.5.0-17-generic); driver: 4.6 (Core Profile) Mesa 23.0.4-0ubuntu1~22.04.1
   0.118   [Extensions] s3tc:yes; KHR_debug:yes; ARB_clear_texture:yes, ARB_copy_image:yes
   0.118   [Version] 4.6
   0.118 Verbose GraphicsInterfaceOpenGL.cpp:944: [Caps] Tex:16384, TexArr:2048, TexBufSz:262143kB; TexUnits:192; UboSz:2097151kB
   0.118 Graphics settings preset: very-high
   0.118   Dedicated video memory size 8192 MB
   0.128 Verbose PipelineStateObject.cpp:89: Time to load shaders: 0.010097 seconds.
   0.133 Graphics options: [Graphics quality: high] [Video memory usage: all] [DXT: high-quality] [Color: 32bit]
   0.133                   [Max threads (load/render): 32/8] [Max texture size: 0] [Tex.Stream.: 0] [Rotation quality: normal] [Other: STDCWT] [B:0,C:0,S:100]
   0.384 [Audio] Backend:SDL(default); Driver:pulseaudio, Device:Default device, Depth:16, Channels:2, Frequency:44100
   0.485 Loading mod core 0.0.0 (data.lua)
   0.510 Loading mod base 1.1.104 (data.lua)
   0.614 Loading mod base 1.1.104 (data-updates.lua)
   0.670 Checksum for core: 607699937
   0.670 Checksum of base: 1054619811
   0.814 Prototype list checksum: 3034860339
   0.816 Verbose ModManager.cpp:608: Time to load mods: 0.3328
   0.844 Loading sounds...
   0.922 Info PlayerData.cpp:78: Local player-data.json unavailable
   0.922 Info PlayerData.cpp:83: Cloud player-data.json unavailable
   0.961 Crop bitmaps.
   1.468 Parallel Sprite Loader initialized (threads: 15)
   4.751 Verbose ParallelSpriteLoader.cpp:183: Sprite loader stats> Worker loaded max size: 72.04MB, Total worker loaded max size: 941.61MB
   4.762 Initial atlas bitmap size is 16384
   4.783 Created atlas bitmap 16384x16372 [none]
   4.785 Created atlas bitmap 16384x13232 [none]
   4.785 Created atlas bitmap 8192x4188 [decal]
   4.785 Created atlas bitmap 16384x5568 [low-object]
   4.785 Created atlas bitmap 8192x4432 [mipmap, linear-minification, linear-magnification, linear-mip-level]
   4.786 Created atlas bitmap 16384x6064 [terrain, mipmap, linear-minification, linear-mip-level]
   4.786 Created atlas bitmap 4096x3216 [terrain-effect-map, mipmap, linear-minification, linear-mip-level]
   4.786 Created atlas bitmap 4096x1840 [smoke, mipmap, linear-minification, linear-magnification]
   4.786 Created atlas bitmap 4096x3104 [mipmap]
   4.786 Created atlas bitmap 8192x2272 [icon, not-compressed, mipmap, linear-minification, linear-magnification, linear-mip-level]
   4.786 Created atlas bitmap 8192x1496 [alpha-mask]
   4.788 Created atlas bitmap 16384x14764 [shadow, linear-magnification, alpha-mask]
   4.788 Created atlas bitmap 8192x2352 [shadow, mipmap, linear-magnification, alpha-mask]
   4.788 Created atlas bitmap 2048x240 [icon-background, not-compressed, mipmap, linear-minification, linear-magnification, linear-mip-level, ]
   4.794 Verbose TextureProcessor.cpp:1125: GPU accelerated compression test: Time 5.687 ms; YCoCg_DXT PSNR: 35.83, BC3 PSNR: 33.82
   4.794 Texture processor created (2048). GPU accelerated compression Supported: yes, Enabled: yes/yes. Test passed. YCoCgDXT PSNR: 35.83, BC3 PSNR: 33.82
   5.275 Parallel Sprite Loader initialized (threads: 15)
   9.258 Sprites loaded
   9.280 Generated mipmaps (4) for atlas [3] of size 16384x5568   
   9.288 Generated mipmaps (3) for atlas [4] of size 8192x4432   
   9.302 Generated mipmaps (3) for atlas [5] of size 16384x6064   
   9.304 Generated mipmaps (3) for atlas [6] of size 4096x3216   
   9.306 Generated mipmaps (3) for atlas [7] of size 4096x1840   
   9.330 Generated mipmaps (3) for atlas [8] of size 4096x3104   
   9.334 Generated mipmaps (5) for atlas [9] of size 8192x2272   
   9.336 Generated mipmaps (3) for atlas [12] of size 8192x2352   
   9.345 Custom mipmaps uploaded (1942)
   9.345 Verbose AtlasSystem.cpp:967: Atlas memory size: 1231.19MB; 0.00MB (virtual)
   9.345 Verbose AtlasSystem.cpp:968: Size of sprites outside of atlas: 0.13MB
   9.345 Verbose ParallelSpriteLoader.cpp:183: Sprite loader stats> Worker loaded max size: 74.02MB, Total worker loaded max size: 996.84MB
   9.411 Factorio initialised
  10.203 Goodbye

and I've even run the win-zip version (virtually) on the same box; it also succeeds, but this time around it actually shows the gui while playing the music, hehe.
fun fact: the (output) folders actually differ (haha) for all 1278 files (win folder came out a bit smaller in size as well). Might look into it on pixels with some scripts later to see if non-meta differs, too lazy-busy rn tho.


While I could fuzz/bin-search for the crashing config, it would be nice to get some pointers on what could be the glaring offender right away
the "uncommented" part of 104 config.ini has these in [graphics]:

Code: Select all

[graphics]
cache-sprite-atlas=true
compress-sprite-atlas-cache=true
graphics-quality=normal
full-screen=false
show-smoke=false
show-clouds=false
show-decoratives=false
show-item-shadows=false
show-inserter-shadows=false
show-tree-distortion=false
v-sync=false
high-quality-animations=false
high-quality-shadows=false
high-quality-terrain=false
show-game-simulations-in-background=false
video-memory-usage=medium

I mean, it should not go down if I do a medium mem usage? Or crank down some shadows? Too lazy-busy to test right now (still, not too much to fuzz about "in total").


as usual, me ready for some more bug crunching...
good luck and have fun with tracing it all up

[KeepResearchinSpoons]

could be triaged as minor issue or duplicate

Okay; to me this seems like a duplicate of a known issue with "linux vram size detection is broken".
mostly means "video-memory-usage" has to be set to "all" (as is by default).

Not sure if it's even worth it on time-investment, assuming the workaround is possible. Not sure if fix-able at all of some specific setups.
Could be a minor issue, could be a duplicate, could be whatever. Not really matters. ¯\_(ツ)_/¯

Casually confirm rsed on 1/0 linux magic policy (2020-05-06)

It's why anytime any linux user makes a bug report I just let it sit for 2 -3 days and a *huge* percent of the time they just self-reply with "nevermind it's working now" or "I fixed it/I broke it earlier with some change I did that I never needed to do but i'm a linux user so I did it anyway just to see what would happen."

97.63159%~ of the time it works every time to just ignore bug reports from linux players

apparently we've made if work yet again. Somehow. So much for capable linux users, I guess.

for those 2 hundred views that came around

set `video-memory-usage=all` in [graphics] section.
here's a small-and-simple JS script that does implement a neat-enough workaround.
mostly to put all the dumps under specific folders data|icons|locales under `/tmp/prefix/` (in RAM-mapped tmpfs).

there is no reason to use JS, but why not. *casually confirms rsed yet again*.
We shall need:

• shelljs (DT) (aka "some" unix commands; used for simplicity sake),
• js-ini (TS) (just about any edit-ini works; even naive regexp one)
• this little sparce ~150 lines file

  example.js

  (7.28 KiB) Downloaded 8 times

After getting the dumps, you *might* want to do some more steps.

recipe normalization at least

Well, with dumping ready and smoking, we are done. Mostly.
But there is a lot of "garbage" in what we've got that we can strip-off and we also need some normalization.
Hardly matters since we can't avoid it (and cuz tmpfs is usually RAM-mounted anyways), but a good note if you have them items many.

• if you use any sort of browser-something or the like, there are 2 major stuff on icons.
  • set a reply header for cache-me-pls
  • and provide predictable static path as to not bork the caching.
  I trust it you can make a hash-based general store for all the dumps icons or maybe even assemble sprite-sheets kirk-like with python's PIL or smth yourself. Not a definitive requirement for localhost anyways.
• you can *probably* drop half the exported json data with noise-stuff. Never gonna need it.
  except... when you try to mimic autoplace ratios stuff? but you need a solid Lua-awareness either way by that time, for milestones, triggers and the like.
  I've made a trivial split-files-by-prototype-class just as a simple example so you can see how much whichever takes.
• recipe data normalization is kinda a cool stuff to consider.
  recipe item could be a `string`, a `[name_string, amount_number]`, or even an object with a "type" key, to name a few.
  • If you think that is all, no. All of it could be boxed under normal/expensive keys. "Fixed" in 2.0, btw. You can't use both same-map anyways. Except for "Journey"-like map with "resets" maybe. Still stands, you probably want to select *either* preset to work your way with anyways.
  • If you think THAT is all, then, well, also no.
    what do you think a spider is? an item? a pigeon? a fluid? no, it's a spider 'of cause.
    I mean, I do have a joke-mod with spider-fluid among other things, but that is unrelated.
    Same goes for grenades, capsules, remotes... you name it.
    Gladly, you get the auto-barelling recipes explicitly available, hehe, lucky.
    And yes, you can also safely set up caching here, since protos data is as static as can be.

I do not really thing this is worthy to get into technical-help forum; but I doubt it has much use in bugs list either.
And since wiki is cumbersome, dated and you get most of your data elsewhere (aside from its policy of no-crude-examples such as this one) this little tool does not belong there anyways. And I doubt the original tool where this part was actually extracted from does it any better.
But if getting-dumps is all you need *and* you have npm/node on your toolbox somehow? then it just works.

Have fun, and may the gear force and fish luck be with you.