Time |
Nick |
Message |
07:14 |
|
rjackson_isl_hom joined #evergreen |
07:17 |
rjackson_isl_hom |
JBoyer++ |
07:57 |
|
RFrasur joined #evergreen |
08:38 |
|
mmorgan joined #evergreen |
09:01 |
|
mantis joined #evergreen |
10:00 |
|
Dyrcona joined #evergreen |
11:48 |
Dyrcona |
So, the segfault in srfsh on Ubuntu 22.04 appears to be caused by a NULL str pointer being passed to atoi in OpenSRF/src/libopensrf/transport_session.c |
11:53 |
Dyrcona |
vim-- # I am stuck in Ctrl-X mode and I can't get out! |
12:00 |
Dyrcona |
So, yeah, passing a null to atoi causes a segfault. I think this points at a possible bug higher up, though. /me will continue checking the back trace after lunch. |
12:04 |
|
jihpringle joined #evergreen |
12:21 |
Dyrcona |
It blows up at line 652 of transport_session.c where it's trying to get the error code. |
12:59 |
miker |
Dyrcona: ugh, that's worse than just srfsh, for sure. it also seems like we should have seen that before :( |
13:05 |
jonadab |
Almost makes you want to code a safe string-to-number routine that checks for null; but then the question is "what would it return", which leads to wanting to return success/error and place the number in an argument, and then the caller has to check the return value... |
13:05 |
Dyrcona |
miker I'm suspecting a change in libxml2, but I'm still poking. Apparently, the messages to/about non-existent services are not logged at loglevel 4. |
13:06 |
Dyrcona |
jonadab: There are solutions for that in some languages, and it can be done in C/C++ as well by returning a struct with the return value and another field to indicate success or failure. |
13:06 |
jonadab |
Dyrcona: Sure, and I'm used to Perl where "" is zero in numeric context. But no solution is perfect. |
13:07 |
Dyrcona |
I'm suspicious of it strictly being changes in libxml2, though because it seems to have no trouble finding the status, etc., from successful messages. |
13:08 |
Dyrcona |
I was thinking of returning multiple values in Lisp or tuples in Python |
13:10 |
* Dyrcona |
cranks loglevel to the "hidden" value of 6. |
13:18 |
|
mantis joined #evergreen |
13:20 |
miker |
ah! libxml could be it, yes. we've run into other issues with it. I could see it changing from empty string to null... |
13:22 |
Dyrcona |
Here's the backtrace: https://pastebin.com/hwZ8z5T9 |
13:22 |
Dyrcona |
I configured with --enable-debug. |
13:24 |
Dyrcona |
miker: That's possibly the culprit. A little test program doesn't crash when I do x = atoi(""); |
13:30 |
Dyrcona |
Ok. If I change line 698 in transport_session.c (get_xml_attr()) to return "" instead of NULL, we don't crash. I'm not sure that's the best fix, however. |
13:32 |
miker |
probably better style to test for null. but ... then do we need to protect a free() later on? (not in a position to dig right now, unfortunately) |
13:33 |
miker |
Dyrcona++ |
13:35 |
miker |
and, entirely unrelated, I've finally uploaded the 3.9 release artifacts to lupin and (thanks to abneiman) the website is pointing at them! (the downloads page could use some love, but changes deserve some thought first) |
13:36 |
jonadab |
Dyrcona: Sure, or returning an object that evalutes to 0 in numeric context, false in boolean context, or "Error: empty string is not numeric" in string context :-) |
13:36 |
jonadab |
And throws an exception if called as code. |
13:38 |
Dyrcona |
No, That's not it, either. :) |
13:40 |
Dyrcona |
miker: Yeah, my change to return "" was just to verify a hunch. I'd really like to figure out why this blows up on Ubuntu 22.04 and not 20.04 or 18.04. I've confirmed with a little test program that passing NULL to atoi segfaults on all 3, which I suspected. |
13:42 |
Dyrcona |
For the logs, if I do "request math add 2,2" that crashes on 22.04 but says "Received no data from server" on earlier distros, and.... that may be a clue that I'm overlooking. We're getting "something" back on 22.04. |
14:01 |
Dyrcona |
Yeah, we're crashing before we get to the point of printing "Received no data from server." It just gets more puzzling the more I look. |
15:32 |
Dyrcona |
gdb is not very much fun... |
17:05 |
|
mmorgan left #evergreen |
18:09 |
|
bgillap joined #evergreen |