Now that I'm back in the slackware fold, I've done some more testing of the changes described below and have still not seen a segfault. So it's looking more and more like B Watson's suggestion, on which my changes are based, was the right idea, and he deserves the thanks of those of us who enjoy using tangogps.<br>
<br>/Don<br><br><div class="gmail_quote">On Fri, Aug 5, 2011 at 3:16 PM, Donald Allen <span dir="ltr"><<a href="mailto:donaldcallen@gmail.com">donaldcallen@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br><br><div class="gmail_quote"><div class="im">On Sun, Jul 31, 2011 at 8:57 PM, Pedro Mendes <span dir="ltr"><<a href="mailto:pedro@gepasi.org" target="_blank">pedro@gepasi.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Too bad, I had already submitted. I think I can pull it out and will<br>
wait for further information from you. We can add a patch to the<br>
slackbuild, this is done in other packages when it cannot be avoided.<br></blockquote></div><div><br>Hi --<br><br>Sorry it has taken me awhile to get back. We had a family emergency that took me away for a couple of days.<br>
<br>
I have not tested tangogps with the changes I installed as thoroughly as I would have liked, but the testing I did resulted in no segfaults, which were pretty easy to provoke before I installed the changes below.<br><br>
I have reached the point where I've had enough problems with slackbuilds and I'm tired of the pain of slackware package management (or lack thereof) that I'm giving debian a try (I found that I could install it without a desktop environment, exactly what I wanted; I just run dwm) and I have to do it on the netbook for various reasons. So I no longer have slackware installed on that machine, so I won't be able to do further testing in a car. But I think it's safe to install the changes below. <br>
<br>Here are the diffs:<br><br>diff src/tile_management.c /home/dca/Software/tangogps-0.99.4/src/tile_management.c<br>249a250<div class="im"><br>> curl_easy_setopt(curl, CURLOPT_NOSIGNAL, 1);<br></div>diff src/util.c /home/dca/Software/tangogps-0.99.4/src/util.c<br>
111a112<br>> curl_easy_setopt(curl_handle, CURLOPT_NOSIGNAL, 1);<br>168a170<br>> curl_easy_setopt(curl_handle, CURLOPT_NOSIGNAL, 1);<br><br>The left-hand files (in src/) as the originals; the right-hand files are the ones I modified, adding the calls to curl_easy_setopt.<br>
<br>I hope this helps.<br><br>/Don<br></div><div><div></div><div class="h5"><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
<br>
thanks<br>
<font color="#888888">pedro<br>
</font><div><div></div><div><br>
On Mon, Aug 1, 2011 at 12:34 AM, Donald Allen <<a href="mailto:donaldcallen@gmail.com" target="_blank">donaldcallen@gmail.com</a>> wrote:<br>
> Pedro --<br>
> I should have copied you on this, because you need to be aware of this<br>
> discussion. We don't have an answer yet, but B Watson may have identified<br>
> the problem. I'll be sure to let you know how my testing turns out. Right<br>
> now, even tangogps 0.99.4 (built from source) is unreliable on slackware<br>
> 13.37. Hopefully, this will fix the problem. More when I know more.<br>
> /Don<br>
><br>
> ---------- Forwarded message ----------<br>
> From: B Watson <<a href="mailto:yalhcru@gmail.com" target="_blank">yalhcru@gmail.com</a>><br>
> Date: Sun, Jul 31, 2011 at 5:39 PM<br>
> Subject: Re: [Slackbuilds-users] tangogps slackbuild doesn't work<br>
> To: "SlackBuilds.org Users List" <<a href="mailto:slackbuilds-users@slackbuilds.org" target="_blank">slackbuilds-users@slackbuilds.org</a>><br>
><br>
><br>
> On 7/31/11, Donald Allen <<a href="mailto:donaldcallen@gmail.com" target="_blank">donaldcallen@gmail.com</a>> wrote:<br>
><br>
>> If you google for 'libcurl "error 6" segfault', you get hits involving all<br>
>> sorts of applications that apparently use curl. Try it. This looks to me<br>
>> like a bug in libcurl. So unless you are feeling better, stay in bed. This<br>
>> appears to be someone else's problem.<br>
><br>
> This sounds really similar to the issue with uget that I dealt with a<br>
> while back.<br>
><br>
> If it's the same issue, it can be fixed by adding<br>
><br>
> curl_easy_setopt(curl, CURLOPT_NOSIGNAL, 1);<br>
><br>
> somewhere in the bit of code that sets the other curl options.<br>
><br>
> The issue is actually documented in the curl API docs: if curl is<br>
> built with threads but without c-ares support (like the one shipped<br>
> with slackware), the default DNS timeout handling (which uses signals,<br>
> presumably SIGALRM) is unsafe.<br>
><br>
> Adding to the confusion is that (at least in the case of uget) this<br>
> didn't actually hurt anything on slackware 13.1, but it does on 13.37.<br>
><br>
> I dunno if you can consider this a bug in curl or not: it's documented,<br>
> but if I were a curl dev, I'd want to fix it (by having CURLOPT_NOSIGNAL<br>
> default to 1 when curl is built without c-ares). Application code can<br>
> set CURLOPT_NOSIGNAL, but I don't know how hard it is for a configure<br>
> script or makefile to detect whether curl was built with c-ares, and I<br>
> don't know what happens if you set CURLOPT_NOSIGNAL when using a libcurl<br>
> with c-ares support.<br>
> _______________________________________________<br>
> SlackBuilds-users mailing list<br>
> <a href="mailto:SlackBuilds-users@slackbuilds.org" target="_blank">SlackBuilds-users@slackbuilds.org</a><br>
> <a href="http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users" target="_blank">http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users</a><br>
> Archives - <a href="http://lists.slackbuilds.org/pipermail/slackbuilds-users/" target="_blank">http://lists.slackbuilds.org/pipermail/slackbuilds-users/</a><br>
> FAQ - <a href="http://slackbuilds.org/faq/" target="_blank">http://slackbuilds.org/faq/</a><br>
><br>
><br>
><br>
<br>
<br>
<br>
</div></div><div><div></div><div>--<br>
Pedro, o guardador de enzimas e computadores<br>
</div></div></blockquote></div></div></div><br>
</blockquote></div><br>