[CURA-13047] 'findFieldByName' now gives null on Windows, but the name exists#16
Conversation
…ough the name exists. This then causes a crash in the error-handling routine (not fixed by this commit), because that triggers when the returned field is a nullptr. proposed solution w.r.t. CURA-13047
wawanbreton
left a comment
There was a problem hiding this comment.
Hmm, I would really like to know more about the root cause of the issue before accepting this fix... It really feels like we are missing something obvious that we should do on our side now.
Also you mention "a crash in the error-handling routine (not fixed by this commit)", so that means if it ever happens that a field is missing, it will still crash ? This is a bit disappointing since the "error-handling routine" is supposed to properly fallback when such a case happens 😅
I could dive into this more deeply, but that would take up time we may not have; let's discuss when you're in the office.
So that's 'just' the set-error bit before the return null -- that is, it sets error information. (The whole return null bit works fine if you remove the 'error handling'.) The reason I didn't fix that is mostly that's done everywhere in this repository; that's how you set the error-information. Secondly, even if I did outright remove that bit (which is honestly a way we may go), we'd still have a crash in the front-end (albeit one that gets you a stack-trace.) |
|
Temp solution to unblock the process of development. Follow up ticket to address properly for internal reference: CURA-13058 |
This then causes a crash in the error-handling routine (not fixed by this commit), because that triggers when the returned field is a
nullptr.(This happened after we upgraded protobuf, and exclusively on Windows.)
Proposed solution, under discussion, since it's quite hacky, and doesn't solve the underlying problem (whatever that actually is).