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 <maxim@maxim-fomin.ru> 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 <sean@invisibleduck.org>
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
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals