Author |
Message |
Henri Beauchamp
Joined: 2009-03-17 18:42:51 Posts: 5523
|
Ok folks, here is a new patched binary for v1.26.18.10: please overwrite the original binary with it, launch it and log in, open the "Advanced" -> "Consoles" -> "Debug tags" floater and check the "Mesh" item in the list. Then try and crash the viewer again, and post the corresponding log/crash dump please. Note that I added extra, paranoid checks over LL's code in this binary, with the corresponding warnings should they get hit: let's see if it makes a difference... On my side, I just spent over 2 hours sim-jumping in SL to busy and mesh-heavy places and still could not crash my viewer... It's a real mystery, so far...
|
2016-06-21 09:59:23 |
|
|
wahrah12
Joined: 2016-06-04 02:30:54 Posts: 42
|
edit
Last edited by wahrah12 on 2016-06-22 12:23:12, edited 1 time in total.
|
2016-06-22 06:40:16 |
|
|
Henri Beauchamp
Joined: 2009-03-17 18:42:51 Posts: 5523
|
Or this is just good luck... Did you change something to your system settings ? Also, I'm interested to know which of the paranoid checks I added gets hit (if at all: if none gets hit, then you just were lucky, or what you last changed on your system cured the issue). Please, look at your logs (i.e. load them into a text editor), and let me know if you see any of the following warnings in them (just search for the quoted strings, quotes excluded); if yes, please also post the log or at least a hundred of lines before the warning and a dozen of lines after it: - "No data received for mesh Id:" .../...
- "Stale response received for removed instance. Ignoring."
- "Called with NULL data ! Ignored."
- "Already optimized, ignoring." (new in the patched version)
- "NULL mIndices, aborting." (new in the patched version)
|
2016-06-22 09:45:01 |
|
|
TheADX
Joined: 2012-02-10 15:12:54 Posts: 80
|
So far no crash but nothing in the logs either. Only thing that i noticed was this:
WARNING: LLMeshLODHandler::processFailure: Error during mesh LOD handling. ID: d5638fb0-699d-c116-d58f-253caa6e3f0d - Reason: Server returned nothing (no headers, no data) (Easy_52). Not retrying.
Not sure if related.
|
2016-06-22 11:20:45 |
|
|
Henri Beauchamp
Joined: 2009-03-17 18:42:51 Posts: 5523
|
No, that's not one of the warnings corresponding to the extra-checks I added. Just watch for the ones I quoted above, please.
|
2016-06-22 11:28:56 |
|
|
TheADX
Joined: 2012-02-10 15:12:54 Posts: 80
|
Got a crash few seconds after login but did not manage to enable mesh debug before that.
|
2016-06-22 18:21:31 |
|
|
Henri Beauchamp
Joined: 2009-03-17 18:42:51 Posts: 5523
|
Yes, same crash (so the extra-checks I added are useless), but without the debug messages in the log, I still can't spot the exact place (Windows mini-crash dumps are not super-informative and don't allow to directly associate the machine code to the C++ line being executed)...
|
2016-06-22 21:12:09 |
|
|
TheADX
Joined: 2012-02-10 15:12:54 Posts: 80
|
Yes, lets hope i can catch it with the mesh debug enabled next time )
|
2016-06-23 08:36:47 |
|
|
TheADX
Joined: 2012-02-10 15:12:54 Posts: 80
|
|
2016-06-23 20:50:44 |
|
|
Henri Beauchamp
Joined: 2009-03-17 18:42:51 Posts: 5523
|
Now, that's interesting !... I think I'm guessing what's happening... The crash occurs during a loop which populates arrays based on vertices and their indices. There's a missing check for an excessive vertex index (i.e. an index above the number of vertices in the mesh) in LL's code; normally, this should not cause a crash, because the array (a STL container) should automatically expand to fit, but there's an affectation of that container element index address into another array just after that, and depending how the compiler optimized it and/or whether the CPU got an out of order execution bug, this could indeed result in a crash (the address would be used before the new, expanded array element is actually allocated)... I still cannot reproduce the bug here (I also tried under Windows today, since the Linux viewer is "desperately" rock-stable and crash-free), but I produced another patched viewer that should avoid that issue (simply aborting the mesh optimization whenever such a bogus vertex index is encountered). Please, download the new patched version here, and let me know if it is stable for you. I'm also interested in long, successful sessions logs, in order to search these logs for warning messages corresponding to extra checks I added.
|
2016-06-23 23:00:28 |
|
|