Re: Segfault in OstcFirmwareCheck::checkLatest
Am 12.01.2020 um 21:00 schrieb Jef Driesen:
On 12/01/2020 20:34, Jan Mulder wrote:
where we expect a string like "[1.5.1]", being the first line in the
http://www.heinrichsweikamp.net/autofirmware/ostc4_changelog.txt file.
So, the problem is not data returned from the DC, but from the webserver
(and totally unprotected parsing at Subsurface end). But, interestingly,
visiting the mentioned changelog file from a browser (or curl), all
looks just fine.
Looks like www.heinrichsweikamp.net redirects to heinrichsweikamp.net,
and subsurface doesn't follow the redirect automatically. This
probably needs to be configured explicitly in the code somewhere.
Hi Jef,
https://www.heinrichsweikamp.net/autofirmware/ostc4_changelog.txt and
https://heinrichsweikamp.net/autofirmware/ostc4_changelog.txt both work
and not redirected. I haven't changed any config for the
heinrichsweikamp.net domain but maybe the non-https requests are now
redirected because of an update (heinrichsweikamp.net is a virtual
("cloud") server only?
Regards,
Matthias
--
heinrichs weikamp gmbh * Adlerstr. 7 * 79098 Freiburg * Germany
Amtsgericht Freiburg HRB 713558 * Gerichtsstand Freiburg im Breisgau
Geschäftsführer: Matthias Heinrichs
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Segfault in OstcFirmwareCheck::checkLatest
On 13 January, 2020 - Gaetan Bisson wrote: > Hi Anton, > > [2020-01-10 16:51:26 -1000] Gaetan Bisson: > > I'll double check later this weekend. > > I can't seem to be able to reproduce the segfault anymore. It could very > well be that I misdiagnosed the problem and was in fact facing the issue > Jan described. Sorry for the confusion. I'd say that the diagnosis about the redirect is correct, and right now the redirect is gone, but there are other problems with http://heinrichsweikamp.net/ returning 403 so they're probably working on something right now. It's clearly shown in the stacktrace that fwParts is empty, so its not the case that its trying to use the update data for a ostc3 and comparing that against a ostc4. Why it took the path of OSTC 4 there I still can't figure out... I'll write it on my eternal todo-list to harden this code, so we don't crash if a network call returns unexpected data. //Anton -- Anton Lundin+46702-161604 ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Segfault in OstcFirmwareCheck::checkLatest
Hi Anton, [2020-01-10 16:51:26 -1000] Gaetan Bisson: > I'll double check later this weekend. I can't seem to be able to reproduce the segfault anymore. It could very well be that I misdiagnosed the problem and was in fact facing the issue Jan described. Sorry for the confusion. Cheers. -- Gaetan ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Segfault in OstcFirmwareCheck::checkLatest
On 12-01-2020 21:00, Jef Driesen wrote: On 12/01/2020 20:34, Jan Mulder wrote: When downloading from an OSTC4, I get the same error. A little investigation shows that in OstcFirmwareCheck::parseOstcFwVersion() a very unexpected string is parsed: " 301 Moved Permanently 301 Moved Permanently" where we expect a string like "[1.5.1]", being the first line in the http://www.heinrichsweikamp.net/autofirmware/ostc4_changelog.txt file. So, the problem is not data returned from the DC, but from the webserver (and totally unprotected parsing at Subsurface end). But, interestingly, visiting the mentioned changelog file from a browser (or curl), all looks just fine. Looks like www.heinrichsweikamp.net redirects to heinrichsweikamp.net, and subsurface doesn't follow the redirect automatically. This probably needs to be configured explicitly in the code somewhere. Yes, thanks Jef, that's it. Just verified things by directly querying http://heinrichsweikamp.net/autofirmware/ostc4_changelog.txt. That works as intended. --jan ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Segfault in OstcFirmwareCheck::checkLatest
When downloading from an OSTC4, I get the same error. A little investigation shows that in OstcFirmwareCheck::parseOstcFwVersion() a very unexpected string is parsed: " 301 Moved Permanently 301 Moved Permanently" where we expect a string like "[1.5.1]", being the first line in the http://www.heinrichsweikamp.net/autofirmware/ostc4_changelog.txt file. So, the problem is not data returned from the DC, but from the webserver (and totally unprotected parsing at Subsurface end). But, interestingly, visiting the mentioned changelog file from a browser (or curl), all looks just fine. @Matthias: any recent change at HW's webserver end that might cause this? --jan On 11-01-2020 03:51, Gaetan Bisson wrote: Hi Anton, [2020-01-10 23:27:04 +0100] Anton Lundin: On 09 January, 2020 - Gaetan Bisson wrote: Hi Anton, [2020-01-09 20:47:59 +0100] Anton Lundin: So, can you re-run this and provide a libdivecomptuer logfile? I'd like to see what the device actually says. Please find the log file attached. Let me know if there's anything else you'd like to know/have. Subsurface: v4.9.3-733-g042799eb2a4e, built with libdivecomputer v0.7.0-devel-Subsurface-NG (4eb34b1466e7dff3ee2c0dfbeeef3642c2166d8c) INFO: Open: name=/dev/ttyUSB0 INFO: Configure: baudrate=115200, databits=8, parity=0, stopbits=0, flowcontrol=0 INFO: Timeout: value=3000 INFO: Sleep: value=300 INFO: Purge: direction=3 INFO: Write: size=1, data=BB INFO: Read: size=1, data=BB INFO: Read: size=1, data=4D INFO: Write: size=1, data=60 INFO: Read: size=1, data=60 INFO: Read: size=5, data=000A00 INFO: Read: size=1, data=4D INFO: Write: size=1, data=69 INFO: Read: size=1, data=69 INFO: Read: size=64, data=090A03074857204F5354432020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020 INFO: Read: size=1, data=4D Event: model=10 (0x000a), firmware=775 (0x0307), serial=2569 (0x0a09) The mind boggles. This device clearly identifies itself as a OSTC 3. How can strcmp(data->product, "OSTC 4") == 0 be true then? Sorry but the device isn't with me right now. I'll double check later this weekend. Cheers. ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Segfault in OstcFirmwareCheck::checkLatest
Hi Anton, [2020-01-10 23:27:04 +0100] Anton Lundin: > On 09 January, 2020 - Gaetan Bisson wrote: > > > Hi Anton, > > > > [2020-01-09 20:47:59 +0100] Anton Lundin: > > > So, can you re-run this and provide a libdivecomptuer logfile? I'd like > > > to see what the device actually says. > > > > Please find the log file attached. Let me know if there's anything else > > you'd like to know/have. > > > > > Subsurface: v4.9.3-733-g042799eb2a4e, built with libdivecomputer > > v0.7.0-devel-Subsurface-NG (4eb34b1466e7dff3ee2c0dfbeeef3642c2166d8c) > > INFO: Open: name=/dev/ttyUSB0 > > INFO: Configure: baudrate=115200, databits=8, parity=0, stopbits=0, > > flowcontrol=0 > > INFO: Timeout: value=3000 > > INFO: Sleep: value=300 > > INFO: Purge: direction=3 > > INFO: Write: size=1, data=BB > > INFO: Read: size=1, data=BB > > INFO: Read: size=1, data=4D > > INFO: Write: size=1, data=60 > > INFO: Read: size=1, data=60 > > INFO: Read: size=5, data=000A00 > > INFO: Read: size=1, data=4D > > INFO: Write: size=1, data=69 > > INFO: Read: size=1, data=69 > > INFO: Read: size=64, > > data=090A03074857204F5354432020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020 > > INFO: Read: size=1, data=4D > > Event: model=10 (0x000a), firmware=775 (0x0307), serial=2569 > > (0x0a09) > > The mind boggles. This device clearly identifies itself as a OSTC 3. > > How can strcmp(data->product, "OSTC 4") == 0 be true then? Sorry but the device isn't with me right now. I'll double check later this weekend. Cheers. -- Gaetan ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Segfault in OstcFirmwareCheck::checkLatest
On 09 January, 2020 - Gaetan Bisson wrote: > Hi Anton, > > [2020-01-09 20:47:59 +0100] Anton Lundin: > > So, can you re-run this and provide a libdivecomptuer logfile? I'd like > > to see what the device actually says. > > Please find the log file attached. Let me know if there's anything else > you'd like to know/have. > > Subsurface: v4.9.3-733-g042799eb2a4e, built with libdivecomputer > v0.7.0-devel-Subsurface-NG (4eb34b1466e7dff3ee2c0dfbeeef3642c2166d8c) > INFO: Open: name=/dev/ttyUSB0 > INFO: Configure: baudrate=115200, databits=8, parity=0, stopbits=0, > flowcontrol=0 > INFO: Timeout: value=3000 > INFO: Sleep: value=300 > INFO: Purge: direction=3 > INFO: Write: size=1, data=BB > INFO: Read: size=1, data=BB > INFO: Read: size=1, data=4D > INFO: Write: size=1, data=60 > INFO: Read: size=1, data=60 > INFO: Read: size=5, data=000A00 > INFO: Read: size=1, data=4D > INFO: Write: size=1, data=69 > INFO: Read: size=1, data=69 > INFO: Read: size=64, > data=090A03074857204F5354432020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020202020 > INFO: Read: size=1, data=4D > Event: model=10 (0x000a), firmware=775 (0x0307), serial=2569 > (0x0a09) The mind boggles. This device clearly identifies itself as a OSTC 3. How can strcmp(data->product, "OSTC 4") == 0 be true then? //Anton - Goes back to fever dreaming -- Anton Lundin+46702-161604 ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Segfault in OstcFirmwareCheck::checkLatest
On 09 January, 2020 - Dirk Hohndel wrote: > > > > On Jan 8, 2020, at 6:13 PM, Gaetan Bisson wrote: > > > > [2020-01-08 15:55:34 -1000] Gaetan Bisson: > >> I just rebuilt subsurface from current git master and am getting a > >> segfault when downloading dives from my OSTC3. The problem appears to be > >> in OstcFirmwareCheck::checkLatest. I'm attaching the full backtrace of > >> the crash. I'll investigate more later unless someone beats me to it. > > > > So the problem seems to be that I've got an OSTC3 yet the following > > assertion holds: > > > > strcmp(data->product, "OSTC 4") == 0) > > > > Since apparently it's libdivecomputer that populates the device_data > > struct, I'd like to report this to them but I don't see any recent > > change that might have broken this, and this issue certainly did not > > exist in mid-december. I'll dig more but for now I'm a bit confused. > > > > So in commit c36513a9f3e77 we changed how we recognize and try to identify > OSTC dive computers via BLE (as that is not always reliably possible), but > that > shouldn't have the result that you describe above. > > Typically Anton is a great resource for all things OSTC and especially the > parts > of our code that configure the OSTC. Maybe he has any ideas? Hmm... We fetched the update info for a OSTC 3 but we got a firmware version for a OSTC 4, and then trying to convert the update info firmware number into something we can compare with the device firmware version we accessed outside a array. First, we should require that we have the right info for the device we're trying to check if we should update, So we compare apples with apples, and not trying to adress elements outside our QStringList. If we get a DC_EVENT_DEVINFO event from libdivecomputer with another product than we provided, we change to that. So, can you re-run this and provide a libdivecomptuer logfile? I'd like to see what the device actually says. //Anton -- Anton Lundin+46702-161604 ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Segfault in OstcFirmwareCheck::checkLatest
> On Jan 8, 2020, at 6:13 PM, Gaetan Bisson wrote: > > [2020-01-08 15:55:34 -1000] Gaetan Bisson: >> I just rebuilt subsurface from current git master and am getting a >> segfault when downloading dives from my OSTC3. The problem appears to be >> in OstcFirmwareCheck::checkLatest. I'm attaching the full backtrace of >> the crash. I'll investigate more later unless someone beats me to it. > > So the problem seems to be that I've got an OSTC3 yet the following > assertion holds: > > strcmp(data->product, "OSTC 4") == 0) > > Since apparently it's libdivecomputer that populates the device_data > struct, I'd like to report this to them but I don't see any recent > change that might have broken this, and this issue certainly did not > exist in mid-december. I'll dig more but for now I'm a bit confused. > So in commit c36513a9f3e77 we changed how we recognize and try to identify OSTC dive computers via BLE (as that is not always reliably possible), but that shouldn't have the result that you describe above. Typically Anton is a great resource for all things OSTC and especially the parts of our code that configure the OSTC. Maybe he has any ideas? /D___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
Re: Segfault in OstcFirmwareCheck::checkLatest
[2020-01-08 15:55:34 -1000] Gaetan Bisson: > I just rebuilt subsurface from current git master and am getting a > segfault when downloading dives from my OSTC3. The problem appears to be > in OstcFirmwareCheck::checkLatest. I'm attaching the full backtrace of > the crash. I'll investigate more later unless someone beats me to it. So the problem seems to be that I've got an OSTC3 yet the following assertion holds: strcmp(data->product, "OSTC 4") == 0) Since apparently it's libdivecomputer that populates the device_data struct, I'd like to report this to them but I don't see any recent change that might have broken this, and this issue certainly did not exist in mid-december. I'll dig more but for now I'm a bit confused. Cheers. -- Gaetan ___ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
