* [Edbrowse-dev] Curl library error @ 2018-01-29 12:09 Chuck Hallenbeck 2018-01-29 14:06 ` Karl Dahlke ` (2 more replies) 0 siblings, 3 replies; 8+ messages in thread From: Chuck Hallenbeck @ 2018-01-29 12:09 UTC (permalink / raw) To: Edbrowse Development Hi Karl and all, Can you confirm that the following gives the same error that it gives me? It fails for me on both Debian and ArchLinux, the failures started within the last week or so. edbrowse "https://www.literotica.com/stories/new_submissions.php" Here's what I get: the curl library returned the following error message while performing the requested operation: Failed writing received data to disk/application Any suggestions appreciated. I just hope it's not another can of worms opening up here. Chuck -- Here too, In Northeast Ohio, The Moon is Waxing Gibbous (94% of Full) When your only tool is a hammer, everything looks like a nail. Sent from Barry's iPhone. ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Edbrowse-dev] Curl library error 2018-01-29 12:09 [Edbrowse-dev] Curl library error Chuck Hallenbeck @ 2018-01-29 14:06 ` Karl Dahlke 2018-01-29 15:19 ` Chuck Hallenbeck 2018-01-29 15:27 ` Chuck Hallenbeck 2018-01-29 16:03 ` Karl Dahlke [not found] ` <alpine.DEB.2.21.1802010449280.1929@debian.pulsar.com> 2 siblings, 2 replies; 8+ messages in thread From: Karl Dahlke @ 2018-01-29 14:06 UTC (permalink / raw) To: edbrowse-dev Sorry but I get no error on that. Did you try: curl https://www.literotica.com/stories/new_submissions.php Karl Dahlke ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Edbrowse-dev] Curl library error 2018-01-29 14:06 ` Karl Dahlke @ 2018-01-29 15:19 ` Chuck Hallenbeck 2018-01-29 15:27 ` Chuck Hallenbeck 1 sibling, 0 replies; 8+ messages in thread From: Chuck Hallenbeck @ 2018-01-29 15:19 UTC (permalink / raw) To: Karl Dahlke; +Cc: edbrowse-dev Karl, when i do: curl "https://www.literotica.com/stories/new_submissions.php" I get a response consisting of 450 lines, about 56K bytes, which I captured but have not yet examined. I think I have been shrinking lately: More and more things are way over my head! Chuck -- Here too, In Northeast Ohio, The Moon is Waxing Gibbous (95% of Full) When your only tool is a hammer, everything looks like a nail. Sent from Erica's iPhone. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Edbrowse-dev] Curl library error 2018-01-29 14:06 ` Karl Dahlke 2018-01-29 15:19 ` Chuck Hallenbeck @ 2018-01-29 15:27 ` Chuck Hallenbeck 1 sibling, 0 replies; 8+ messages in thread From: Chuck Hallenbeck @ 2018-01-29 15:27 UTC (permalink / raw) To: Karl Dahlke; +Cc: edbrowse-dev Karl, I wrote too soon. I opened the results of the curl output with edbrowse, used the b command to render it, and get the expected and familiar page I was unable to get when edbrowse accessed that URL directly. Chuck -- Here too, In Northeast Ohio, The Moon is Waxing Gibbous (95% of Full) When your only tool is a hammer, everything looks like a nail. Sent from Mable's iPhone. ^ permalink raw reply [flat|nested] 8+ messages in thread
* [Edbrowse-dev] Curl library error 2018-01-29 12:09 [Edbrowse-dev] Curl library error Chuck Hallenbeck 2018-01-29 14:06 ` Karl Dahlke @ 2018-01-29 16:03 ` Karl Dahlke 2018-01-29 16:53 ` Chuck Hallenbeck [not found] ` <alpine.DEB.2.21.1802010449280.1929@debian.pulsar.com> 2 siblings, 1 reply; 8+ messages in thread From: Karl Dahlke @ 2018-01-29 16:03 UTC (permalink / raw) To: edbrowse-dev [-- Attachment #1: Type: text/plain, Size: 876 bytes --] Someone on stack overflow says that error is typically caused by a callback returning the wrong / unexpected number of bytes. These callbacks are at http.c line 2069 and line 299. Not sure how either of these functions could return the wrong number of bytes (assuming you're not downloading a page directly to disk, with not enough room on disk, which is really unlikely). Very first line computes the number of bytes to return. If the bug were here I might put in some prints to see the arguments and the bytes returned. Or you might use git to back up a couple weeks, although nothing we've done in the past month has touched that file, so that's a longshot. git checkout df7c3d74890026fc1acbfabdbb5a7b82c12cbc4d It will yammer about a detatched head. Rebuild and test. But make sure you git checkout master to get back to current code. Karl Dahlke ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Edbrowse-dev] Curl library error 2018-01-29 16:03 ` Karl Dahlke @ 2018-01-29 16:53 ` Chuck Hallenbeck 2018-01-29 17:37 ` Dominique Martinet 0 siblings, 1 reply; 8+ messages in thread From: Chuck Hallenbeck @ 2018-01-29 16:53 UTC (permalink / raw) To: Karl Dahlke; +Cc: edbrowse-dev Karl, The df command tells me this about the partition where Debian is running: /dev/sda2 167G 95G 64G 60% / so that's not it, it's only about 56K I'm trying to download. May "typically caused" is a clue. Maybe there are other "atypical causes" at work here. I occasionally visit that service at two different access points, one uses the http protocol, and the other the https protocol. The former still works, it's the latter that doesn't. In recent weeks, what with the Amazon login issue, I've been diligent about keeping apace with the modifications , often checking a couple of times a day. I have identical setups on Debian and on ArchLinux, both are "rolling releases," and this current problem was detected at the same time on both. The http address that still works is for their "search page" and the other, using https, is for their daily updates "what's new today" page. I am not a registered user at this service, they seem not to mind lurkers. But both the http and the https portals have worked flawlessly for me forever until sometime middle or late last week, can't be too sure. Coincidences do happen of course, but the timing suggests an unintended consequence of some essential changes to edbrowse have affected the secure protocol and not the other one. If I decide to backtrack, it makes sense to do so stepping backward a day at a time until I can once more access that site. But what would that tell us? I need to think about that. Chuck -- Here too, In Northeast Ohio, The Moon is Waxing Gibbous (95% of Full) When your only tool is a hammer, everything looks like a nail. Sent from Sonia's iPhone. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Edbrowse-dev] Curl library error 2018-01-29 16:53 ` Chuck Hallenbeck @ 2018-01-29 17:37 ` Dominique Martinet 0 siblings, 0 replies; 8+ messages in thread From: Dominique Martinet @ 2018-01-29 17:37 UTC (permalink / raw) To: Chuck Hallenbeck; +Cc: Karl Dahlke, edbrowse-dev Chuck Hallenbeck wrote on Mon, Jan 29, 2018: > If I decide to backtrack, it makes sense to do so stepping backward a > day at a time until I can once more access that site. But what would > that tell us? If you're up for it, git has a 'bisect' command where it goes halfway in history everytime and you tell it if the commit works or doesn't work. (If required you can also tell it "this commit doesn't work for a different reason and I cannot test", which will give you another commit close-ish to test again) That will tell you precisely which commit changed the behavior and we can look into it. But first, please make sure going back to some old version like the commit Karl pointed at makes it work again -- I tried on a slightly outdated archlinux (last upgrade is two weeks old) and it works just fine, so your problem could be due to some system upgrade instead. Or, since you're pointing at the https version, it could be a TLS problem.... But we should get that too in that case, it is odd. -- Dominique ^ permalink raw reply [flat|nested] 8+ messages in thread
[parent not found: <alpine.DEB.2.21.1802010449280.1929@debian.pulsar.com>]
* [Edbrowse-dev] Curl library error [not found] ` <alpine.DEB.2.21.1802010449280.1929@debian.pulsar.com> @ 2018-02-01 18:08 ` Karl Dahlke 0 siblings, 0 replies; 8+ messages in thread From: Karl Dahlke @ 2018-02-01 18:08 UTC (permalink / raw) To: Edbrowse-dev [-- Attachment #1: Type: text/plain, Size: 1175 bytes --] Chuck ran: > git checkout df7c3d74890026fc1acbfabdbb5a7b82c12cbc4d That build is as of Jan 14. Do this. git log -40 >/tmp/logs That gives a summary of the last 40 commits. Find the one you used df7c3d74890026fc1acbfabdbb5a7b82c12cbc4d and note its date Jan 14. So you are running as of Jan 14. You can roll back to any commit on any date. But it sounds like edbrowse as of Jan 14 still fails today, though you believe it did not fail on Jan 14. That does not 100% let me off the hook, I still might have a problem somewhere that was uncovered by a newer version of curl or some such, software is complicated. You might check your packages to see if curl or libcurl or libcurl-devel has been upgraded since then, particularly if one of libcurl or libcurl-devel was upgraded and not the other. Of course these are fedora names of packages, not sure about your package manager. Maybe someone on arch or debian can help you with this. Possibly the library got auto-updated and not the corresponding header files, making them out of sync. Or maybe just check time stamps with ls for /bin/curl, /lib/libcurl.so, and /usr/include/curl/curl.h. Karl Dahlke ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2018-02-01 18:08 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-01-29 12:09 [Edbrowse-dev] Curl library error Chuck Hallenbeck 2018-01-29 14:06 ` Karl Dahlke 2018-01-29 15:19 ` Chuck Hallenbeck 2018-01-29 15:27 ` Chuck Hallenbeck 2018-01-29 16:03 ` Karl Dahlke 2018-01-29 16:53 ` Chuck Hallenbeck 2018-01-29 17:37 ` Dominique Martinet [not found] ` <alpine.DEB.2.21.1802010449280.1929@debian.pulsar.com> 2018-02-01 18:08 ` Karl Dahlke
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).