2024-09-05 Triaging module meeting

Triaging Module Meeting

Biweekly Triaging module meeting for planning and coordination.
Folks on the payroll should attend if possible, others are invited as well.
In these meetings, we can keep us up-to-date on everything triaging, discuss recent important issues and see if we can bring the module forward.
I believe it is also good to see human faces once in a while :), so there is always room for some personal stuff if appropriate.

The meeting will be on 2024-09-05T11:00:00Z. It is open for everybody interested to join the video call (link below).

Links

Attendees

@Alaska
@ChengduLittleA
@iss
@lichtwerk

Topics

Meeting Notes

  • Pending TODOs/followups (wont get an active topic if no news have to be announced)
    • Feedback regarding our triaging infrastructure
    • Other discussion
      • It was brought up that there have been recent reports of failing physics involving dependency cycles, typically related to this dependency cycle change.
        • How should these be handled? These changes seem to be expected so we can probably close them.
        • Yiming will try to find a few examples and bring them to Blender chat for further discussion.
        • There was discussion around exposing dependency cycles to the user. This was generally agreed upon as a good idea to help expose this information to users and developers.
      • We also discussed the idea of exposing simple debugging tools for triagers and developers. Examples include user_map for checking dependencies, and Validate mesh. We could make a addon or ask a developer to implement this for us.
        • Philipp will put this on their TODO.
      • Could we add a feature that lets users know the location of crash logs after Blender crashes so they can more easily provide it in a bug report?
        • TODO: Check with developers that are more knowledgable in this area on if they want this feature, how they want to implement it, etc.
        • Ask developers why the stack trace on Linux is missing useful information. Figure out how easy it is to fix.
        • Do we want a feature to automatically make bug reports? Like this earlier Crash pad patch?
          • In previous Triaging meetings we have generally agreed that we don’t want this feature as crash logs are missing extra useful information (E.g. Steps to reproduce). But we may want to re-evaluate this.

Following meeting

The following meeting will be on 2024-09-19T11:00:00Z. Again it will be open for everybody who’s interested.

5 Likes

I remember this topic coming up in rocket chat, posting the relevant snippet of discussion here so it doesn’t get lost.

mont29:
stacktrace on linux is useless because we hide all symbols from Blender afaik
Used to work because back in the day we had a selective approach to what we hide, now we essentially hide everything

mont29:
Am not the most versed in this area, but i remember stacktrace became useless after blender/symbols_unix.map at main - blender - Blender Projects was changed to hide almost everything

The only useful tool currently is ASAN, as it does not seem to be bothered by hidden symbols :wink:

LazyDodo:
I’d check if we build with -g or not on linux, on windows the ship the symbols explicitly on release builds for the sole purpose of getting stack traces, they are large but worth the price

5 Likes