I can reproduce it :
alias cower="cower -t ~/Downloads"
[19:23 faelar ~] pacman -Qs cower
A simple AUR agent with a pretentious name
[19:00 faelar ~] cower -ud --debug
debug: Initializing alpm
debug: download requested: discount
debug: Initializing curl handle
debug: Fetching URL http://aur.archlinux.org/packages/disco … unt.tar.gz
:: discount downloaded to /home/faelar
debug: releasing handles
Only thing I can say is double check to make sure .bashrc is actually getting sourced. 'alias cower' alone will show the effective alias, or an error if there's none defined.
edit: man, the debugging in 2.x sucks. it's actually useful in 3.x!
$ ./cower --debug -dt tmp discount debug: adding discount to targets debug: initializing curl debug: initializing alpm debug: setting alpm RootDir to / debug: setting alpm DBPath to: /var/lib/pacman/ debug: ignoring package: make debug: registering alpm db: testing debug: registering alpm db: core debug: registering alpm db: extra debug: registering alpm db: community-testing debug: registering alpm db: community debug: working directory set to: /home/noclaf/src/c/cower/tmp debug: thread[0xb72eeb70]: spawned with arg: discount debug: thread[0xb72eeb70]: locking alpm mutex debug: thread[0xb72eeb70]: unlocking alpm mutex debug: performing curl operation on http://aur.archlinux.org/rpc.php?type=info&arg=discount debug: ---> thread[0xb72eeb70]: entering critical debug: <--- thread[0xb72eeb70]: leaving critical :: discount downloaded to /home/noclaf/src/c/cower/tmp debug: thread[0xb72eeb70]: joined debug: releasing curl debug: releasing alpm
Last edited by falconindy (2010-11-18 18:42:05)
My bash prompt is set correctly, and I did not change my .bashrc between the updates. Plus, cower -s works as intended. That's why I believe this is a change in cower that leads me to this error...
Output of alias cower :
[18:54 faelar ~] alias cower
alias cower='cower -t ~/Downloads'
It's not a big deal though, I can leave with that
no, really.. is something wrong with your shell.. on zsh is working ok.
└─╼ alias cower
cower='cower -t ~/Downloads'
└─╼ cower -d kernel26-slk
:: kernel26-slk downloaded to /home/bogdan/Downloads
Definitly something related to cower. I downgraded to version 2.5.3 and it works as expected :
[21:07 faelar ~] cower -ud
!! /home/faelar/Downloads/cower already exists.
Use -f to force this operation.
!! /home/faelar/Downloads/discount already exists.
Use -f to force this operation.
Holy crap! I've been wanting something like this forever... Thanks a million!
cower: segfault at 7ff5173018cc ip 00007ff5186ba0c2 sp 00007ff5141f1ee8 error 7 in libcurl.so.4.2.0[7ff518691000+53000]
indeed. but this segfault wasn't there using the previous version of cower..
Is this something you can reliably reproduce? If it is, I need you to:
1) re-compile openssl with PURIFY. Get the PKGBUILD from abs and add 'CPPFLAGS=-DPURIFY' to the make invocation.
2) post the output of: LD_PRELOAD=/path/to/purified/libcrypto.so valgrind cower --debug -u --target .... --color
If not, I have a few ideas of my own I'll be looking into tonight.
I'm pretty sure this is a libcurl issue. A timeout is handled just like any other error, so task_query returns NULL just as it would if you were to get a 404 response. The line that sets the timeout is line 587 in 2.9.9:
curl_easy_setopt(handle, CURLOPT_CONNECTTIMEOUT, 10L);
Can you delete this and see if cower behaves?
Last edited by falconindy (2010-12-30 21:31:23)
Ok, that's somewhat reassuring, but I have one other thought. Put the timeout back in, and right after that line, add the following:
curl_easy_setopt(handle, CURLOPT_NOSIGNAL, 1L);
I suspect this is a better solution (provided it works, and I think it will).
Yeah but those are the kinds of errors that I'm happier to see. No segfaults on timeouts! Hurray for me bothering to RTFM.
The connect timeout is 10 seconds, which I thought was more than sufficient. Is cower really taking 10 seconds to connect?
Note to self: need better thread info on some of that debug output...
~20 seconds in fact..
although time cower --color=always --target /home/bogdan/pkgbuilds -u output is 0.53s user 0.04s system 2% cpu 20.494 total
no, it's not geographic/ISP thing. like i said before, the previous version worked ok. right ~1 min after i upgraded it to the last version, bum, segfaults & timeouts..
right now i'm using
curl_easy_setopt(handle, CURLOPT_CONNECTTIMEOUT, 30L); curl_easy_setopt(handle, CURLOPT_NOSIGNAL, 1L);
no timeouts & no segfaults.. i hope you find a fix for this soon..
well, i tested it again to be exact.. ~20-25 sec.. and there are not any segfaults and timeouts errors.
from a diff, i see that "curl_easy_setopt(handle, CURLOPT_CONNECTTIMEOUT, 10L);" is new to 2.9.9.. i think is related to this in some way..