Adal Chiriliuc wrote:
> > I assume 'curl' in that build is working properly with HTTPS?
>
> Yes, the built 'curl' works with HTTPS. But even my plugin, when built as an application with a thrown in main() works with HTTPS.
>
> > I would do 'nm' on the built executable to see that there are SSL-related
> > libcurl function names in there.
>
> I did run 'nm' on my plugin .so. I do see SSL functions in there (all with T, a few D), including Curl_ossl_version.
>
> > I would set a break-point in libcurl's findprotocol() function and see for
> > myself how it looks like. And then possibly also in curl_version_info() and
> > single-step trough to fully understand what's going on there as well.
>
> Like I said in the original mail, I can't attach to the process hosting my plugin (attaching fails). I can't run it myself under the debugger, since it's actually spawned by another master process (think Google Chrome and it's child proceses which host plugins). And there seems to be no DebugBreak Windows like functionality on Linux which can automatically attach the debugger when you call it (SIGTRAP didn't work, because I must be already attached to get the signal).

Normally you should be able to fork and exec gdbserver to attach to your
process, and then attach to gdbserver using gdb from a terminal.

However if attaching fails, it may be some of the complicated stuff
Chrome does itself using ptrace (normally the debugger interface),
which prevents debugging it because only one "debugger" can attach at
a time. Since the Chrome developers might want to debug it, perhaps
there is a Chrome option to turn off the ptrace sandboxing?

-- Jamie
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2010-04-17