Re: wget and WebKit?

[Tim Rühsen]

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.
>
> > Because
> > 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 ?
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";
#endif
```
and this code at L2094
```
#ifdef SIGUSR1
  signal (SIGUSR1, redirect_output_signal);
#endif
```

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

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

Regards, Tim

OpenPGP_signature
Description: OpenPGP digital signature