I'm closing this as WFM because the bug isn't limited only to firefox.
Any application that calls getaddrinfo quickly enough will trigger it.
Rex, I didn't find anything strange in any config file you've posted. I
tried to reproduce it on Fedora and Valentin tried it on Ubuntu, but we
were unable
Is there any change if you remove wins resolving? I.e. in
/etc/nsswitch.conf change line "hosts: files wins dns" to "hosts: files
dns" and rerun the test.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/
Created attachment 9042103
test with pauses
(In reply to rex from comment #79)
> Firefox continues to resolve addresses correctly.
>
> Do we know of a difference between Firefox and Chromium in how they interact
> with wins? This may provide further answers as to why Firefox has difficulty
> w
Now, it seems to resolve normally. I guess firefox shouldn't fail
anymore. Please, test it for a while without wins resolving. I'm not
sure what's exactly wrong, but according to the rule in nsswitch.conf
dns request should be sent when the host isn't found using wins and
because no request is sent
Created attachment 9041202
test.tgz
getaddrinfo fails with EAI_SYSTEM and errno should contain details, but
it's 0.
Could you please extract the attached archive and run "make" in the
extracted directory? It should generate few files in logs directory. I'm
curious whether getaddrinfo called from
Give a try to both versions. And if it's not reproducible in this 66.0a1
build but is reproducible in 65.0b8, I'll create a testing build from
the same source tree.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad
Thanks, unfortunately this log doesn't contain useful information. I
suggested it mainly to check if removing sync helps with reproducing.
Helpful would be the log from my version which logs the error code.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is su
Created attachment 9040578
log_getaddrinfo_errors.c
You could give this version a try. It only prints error message in case
of failure. Use it as the other versions, i.e. compile with:
gcc -shared -ldl -fPIC log_getaddrinfo_errors.c -o
log_getaddrinfo_errors.so
And run it with the official firef
(In reply to rex from comment #60)
> I am able to reproduce the issue with the plain 66.0a1 alpha from a shell
> script or otherwise.
>
> I am not able to reproduce the issue with the plain 66.0a1 alpha from a shell
> script that calls out:
> export MOZ_LOG=timestamp,sync,GetAddrInfo:5,nsHostRe
Can you please try a special build where I've added a code to log error
returned by GetAddrInfo? The try push is here:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=a9fbc1eae0ad3b6989fd2d2e42b449ae371f8ca0&selectedJob=225192845
Linux builds can be downloaded from:
32-bit -
https://queu
(In reply to rex from comment #50)
> Gladly!
> With only 'nameserver 217.23.2.11' in my /etc/resolv.conf and running sudo
> /etc/init.d/dns-clean start, I appear to be completely unable to resolve any
> name in any of my internet browsers. The dump.pcap simply shows entries like
> 'Standard que
Could you please put only "nameserver 217.23.2.11" to /etc/resolv.conf
and provide HTTP log (the same as in comment #13) and dump of DNS
packets when the failure happens? Use tcpdump to dump the DNS packets:
sudo tcpdump -w /tmp/dump.pcap -s 0 udp and port 53 and host 217.23.2.11
--
You received
(In reply to rex from comment #39)
> Hi :michal, using the gcc command for either one now is about
instantaneous and produces no stderr output.
I meant the output when you run it. You should have output like this in
the console:
getaddrinfo node=detectportal.firefox.com, service=(null),
hints=0
It should work. Did it compile without any warning?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1796979
Title:
Intermittently can't connect to the server
To manage notifications about this bug go
(In reply to rex from comment #23)
> Hey Michal, sorry if I completely misunderstand, but does your hook
ask the system to resolve the address before firefox makes the attempt?
I have a hunch that, where firefox would fail to resolve an address, if
another program or service had already resolved t
(In reply to rex from comment #36)
> :michal, it took about 5 seconds to compile and did not return
anything to the terminal.
So, how the output written to stderr by hook3.so (which resolves
correctly) looks like?
--
You received this bug notification because you are a member of Ubuntu
Bugs, wh
Functions from glibc should be called in both cases (with the LD_PRELOAD
as well as without it). Do you run the same firefox binary with the same
environment? I.e. when running firefox without the hook, do you run it
from console as well? Also, does LD_PRELOAD variable contain anything by
default?
You could try to put ISP's DNS servers to /etc/resolv.conf to make sure
dnsmasq doesn't mess anything up.
I still don't understand why nothing is resolved when hook3_test1.so is
preloaded. I will try to come with something else later.
--
You received this bug notification because you are a membe
Could you please also provide you DNS setup? Content of /etc/resolv.conf
and line beginning with "hosts" from /etc/nsswitch.conf. If your
resolv.conf contains 127.0.0.53 then also an output from "systemd-
resolve --status".
--
You received this bug notification because you are a member of Ubuntu
> I couldn't find how to determine what my LD_PRELOAD variable is by
default, but I ran a script with 'echo "LD_PRELOAD IS ${LD_PRELOAD}"'
and starting up firefox which did not return anything after "LD_PRELOAD
IS ". Not sure if that is applicable though. Is there a different way I
should check?
R
(In reply to rex from comment #44)
> The original hook3 running firefox provides output like yours:
> gethostbyname_r=myhostname, retval=0, succeeded
> address: 127.0.1.1
> gethostbyname_r=myhostname, retval=0, succeeded
> address: 127.0.1.1
> getaddrinfo node=detectportal.firefox.com, service
Created attachment 9038810
hook3_test1
Thanks for doing the test. Please, try this new file. It only intercepts
the function call but does nothing with the result.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad
(In reply to Honza Bambas (:mayhemer) from comment #16)
> Thanks. Dragana, Michal, Valentin, any ideas what more to check here?
In bug 1439780 there is a simple program (hook3.c) that hooks resolver
functions and dumps info to standard error, see
https://bugzilla.mozilla.org/show_bug.cgi?id=1439
Comment on attachment 8398993
Part1. FTP client detects UTF-8 if server returns UTF8 on FEAT
Review of attachment 8398993:
-
Sorry for the delay, r+ with fixed indentation
::: netwerk/protocol/ftp/nsFtpConnectionThread.cpp
@@ +657,5
Comment on attachment 570960
Part 3. FTP directory list sets the encoding when current FTP server supports
UTF-8 v2
> + channel->GetContentCharset(mCharset);
> + if (mCharset.EqualsLiteral("UTF-8")) {
> + // For RFC 2640 support, charset is into HTML, not channel.
> + // So we nee
Comment on attachment 571265
Part 2. "301: " works on nsIndexedToHTML correctly v2
> +nsresult
> +nsIndexedToHTML::OnHeaderAvailable(nsIRequest* request, nsISupports
> *aContext,
> + nsString& aBuffer)
I think the name of the method is confusing. A name like Wri
Makoto, I've tested your patch and before going any further with the
review I'd like to get back to comment #54. With this patch applied I
can't browse directories in ftp://ftp.asu.ru/incoming/
The situation is now different in that ftp.asu.ru already supports FEAT
command and returns UTF8. Those
27 matches
Mail list logo
