[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: wget and WebKit?

From: Josef Moellers
Subject: Re: wget and WebKit?
Date: Mon, 27 Jun 2022 08:46:33 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1

On 25.06.22 12:52, Tim Rühsen wrote:
On 20.06.22 09:15, Josef Moellers wrote:
On 18.06.22 16:11, Tim Rühsen wrote:
Moin Josef,

Mooi'n Tim,

is it possible that 'wget' is linked to something else or is a different binary than expected ? Or maybe 'wget' is a script or alias ?

I had asked for straces and they show that "/usr/bin/wget/" is indeed the binary executed.

a) webkit and wget have nothing in common
That was my impression, too. Thanks for confirming! However ... see below ...

b) That message you got seems not be originated in GNU Wget
Yes, it comes from WebKit (Source/WTF/wtf/posix/ThreadingPOSIX.cpp).

I am also discussing this internally with people more familiar with proxy handling. "wget" is linked against libproxy and that may invoke WebKit.

So we're now pursuing the "wget" -> "libproxy" -> "WebKit" trail.

Does SUSE by any chance add their own patches to wget or any of the linked libraries ?

Shame on me: Yes, we do. We have one patch that does indeed add libproxy support. It's been in there for ~12 years :-(

The bug is now with the libproxy folks.

Sorry for the hassle.

Or is there some LD_PRELOAD magic involved ?

Signal 10 is SIGUSR1, and wget sets a signal handler for it in src/main.c L122:
/* Hangup signal handler.  When wget receives SIGHUP or SIGUSR1, it
    will proceed operation as usual, trying to write into a log file.
    If that is impossible, the output will be turned off.  */

To change wget's behavior, you have to comment out this code:
#ifdef SIGUSR1
   if (sig == SIGUSR1)
     signal_name = "SIGUSR1";
and this code at L2094
#ifdef SIGUSR1
   signal (SIGUSR1, redirect_output_signal);

At least it explains
"Overriding existing handler for signal 10. Set JSC_SIGNAL_FOR_GC if you want WebKit to use a different signal"

It was one of the first things I suggested, but it didn't help.


Maybe switch to SIGUSR2 (signal #12 on x86/ARM) via JSC_SIGNAL_FOR_GC !?

Regards, Tim

SUSE Software Solutions Germany GmbH
Frankenstraße 146
90461 Nürnberg

Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
(HRB 36809, AG Nürnberg)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]