This is on OSX. I'll have to come up with a functional minimal example. On Jan 17, 2013, at 2:13 PM, Maxim Fomin <[email protected]> wrote:
> Are you debugging this on OSX? > > In linux these three runs fine and throws exceptions because of absent URL. > However after adding "dlang.org" argument in each of three cases to watch > performance, > valgrind shows memory errors which are finally detected in druntime > (gc.gcx.mark, gc.gcx.findpool, etc.), > so there is something wrong with curl module or druntime. > > Does valgrind detect errors in your installation for #1 and #3? > > 2013/1/17 Sean Kelly <[email protected]> >> Here are three variations of code using the curl client. The first works, >> the second fails with a segfault, and the third works: >> >> >> #1 >> >> void main() { >> auto http = HTTP(); >> go(http); >> } >> >> void go(ref HTTP http) { >> // compose request >> http.perform(); >> } >> >> works! >> >> >> #2 >> >> void main() { >> HTTP http; >> init(http); >> go(http); >> } >> >> void init(ref HTTP http) { >> http = HTTP(); >> } >> >> void go(ref HTTP http) { >> // compose request >> http.perform(); >> } >> >> segfault! (see below) >> >> >> #3 >> >> void main() { >> HTTP http; >> init(http); >> go(http); >> } >> >> void init(ref HTTP http) { >> http.__ctor(null); >> } >> >> void go(ref HTTP http) { >> // compose request >> http.perform(); >> } >> >> works! >> >> >> I'm guessing the segfault in the second case is a compiler bug, but I >> haven't tried to narrow it down yet. The problem initially came up because >> I wanted to use the HTTP struct as a class member, and the documented means >> for initializing it was causing a segfault. Here's the stack trace: >> >> >> Program received signal EXC_BAD_ACCESS, Could not access memory. >> Reason: KERN_PROTECTION_FAILURE at address: 0x00000001000028ec >> 0x0000000100077803 in >> D3std3net4curl4HTTP15onReceiveHeaderMFNdDFxAaxAaZvZv12__lambda2026MFxAaZv () >> (gdb) bt >> #0 0x0000000100077803 in >> D3std3net4curl4HTTP15onReceiveHeaderMFNdDFxAaxAaZvZv12__lambda2026MFxAaZv () >> #1 0x0000000100078bfd in >> D3std3net4curl4Curl15onReceiveHeaderMFNdDFxAaZvZv12__lambda2029MFxAaZv () >> #2 0x0000000100078e75 in >> _D3std3net4curl4Curl22_receiveHeaderCallbackUxPammPvZm () >> #3 0x00007fff98ed6eb9 in Curl_client_write () >> #4 0x00007fff98ed616f in Curl_http_readwrite_headers () >> #5 0x00007fff98eebe11 in Curl_readwrite () >> #6 0x00007fff98eed709 in Curl_do_perform () >> #7 0x0000000100078a3b in D3std3net4curl4Curl7performMFbZi () >> #8 0x00000001000770f8 in D3std3net4curl4HTTP8_performMFbZi () >> #9 0x0000000100076e9a in D3std3net4curl4HTTP7performMFZv () >> #10 function go(ref HTTP) >> #11 function main() >> >> >> Can someone confirm that either the static opCall method that HTTP uses for >> initialization is bad and should be changed, or that this is a compiler >> issue? >> _______________________________________________ >> dmd-internals mailing list >> [email protected] >> http://lists.puremagic.com/mailman/listinfo/dmd-internals > > _______________________________________________ > dmd-internals mailing list > [email protected] > http://lists.puremagic.com/mailman/listinfo/dmd-internals
_______________________________________________ dmd-internals mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/dmd-internals
