Added Gentoo Gnome herd as requested in https://bugs.gentoo.org/show_bug.cgi?id=186452

I have an very similar errror here,too.


PASS: base64_test

=====> Testing GET 
         * GET operation ok: received 3201 bytes.

=====> Testing POST 
         * POST operation ok: received 965 bytes.
         * oops, could not find ListPrice for CD Album Massive Attack, Blue Lines in data returned :|

=====> Testing binary GET 
         * GET operation ok: received 11230 bytes.
         * PNG signature ok
         * image width x height = 500 x 100

=====> Testing GET with redirect 
         * GET operation with redirect ok: received 129429 bytes.

=====> Testing GET with redirect 
         * GET operation with redirect ok: received 24716 bytes.

=====> Testing gnet_conn_http_run(): 
         * gnet_http_get() succeded (buflen = 8182, code = 200).
------------------------------------------------------------
GET (html)                 OK
GET (binary)               OK
POST                       OK
Redirect (same host)       OK
Redirect (different host)  OK
gnet_http_get()            OK
------------------------------------------------------------
PASS: conn_http_test
PASS: hash_test
PASS: inetaddr_test
PASS: ipv6_test
FAILURE: test #10800 at byte 0
        output   : 00000000
        should be: 04030201
FAILURE: test #10800 at byte 1
        output   : 00000000
        should be: 04030201
FAILURE: test #10800 at byte 2
        output   : 00000000
        should be: 04030201
FAILURE: test #10800 at byte 3
        output   : 00000000
        should be: 04030201
FAILURE: test #10801 at byte 0
        output   : 00000000
        should be: 04030201
FAILURE: test #10801 at byte 1
        output   : 00000000
        should be: 04030201
FAILURE: test #10801 at byte 2
        output   : 00000000
        should be: 04030201
FAILURE: test #10801 at byte 3
        output   : 00000000
        should be: 04030201
FAILURE: test #10810 at byte 0
        output   : 00000000
        should be: 040302f1
FAILURE: test #10810 at byte 1
        output   : 00000000
        should be: 040302f1
FAILURE: test #10810 at byte 2
        output   : 00000000
        should be: 040302f1
FAILURE: test #10810 at byte 3
        output   : 00000000
        should be: 040302f1
FAILURE: test #10811 at byte 0
        output   : 00000000
        should be: 040302f1
FAILURE: test #10811 at byte 1
        output   : 00000000
        should be: 040302f1
FAILURE: test #10811 at byte 2
        output   : 00000000
        should be: 040302f1
FAILURE: test #10811 at byte 3
        output   : 00000000
        should be: 040302f1
FAILURE: test #10820 at byte 0
        output   : 00000000
        should be: f4030201
FAILURE: test #10820 at byte 1
        output   : 00000000
        should be: f4030201
FAILURE: test #10820 at byte 2
        output   : 00000000
        should be: f4030201
FAILURE: test #10820 at byte 3
        output   : 00000000
        should be: f4030201
FAILURE: test #10821 at byte 0
        output   : 00000000
        should be: f4030201
FAILURE: test #10821 at byte 1
        output   : 00000000
        should be: f4030201
FAILURE: test #10821 at byte 2
        output   : 00000000
        should be: f4030201
FAILURE: test #10821 at byte 3
        output   : 00000000
        should be: f4030201
FAILURE: test #10900 at byte 0
        output   : 00000000
        should be: 04030201
FAILURE: test #10900 at byte 1
        output   : 00000000
        should be: 04030201
FAILURE: test #10900 at byte 2
        output   : 00000000
        should be: 04030201
FAILURE: test #10900 at byte 3
        output   : 00000000
        should be: 04030201
FAILURE: test #10901 at byte 0
        output   : 00000000
        should be: 04030201
FAILURE: test #10901 at byte 1
        output   : 00000000
        should be: 04030201
FAILURE: test #10901 at byte 2
        output   : 00000000
        should be: 04030201
FAILURE: test #10901 at byte 3
        output   : 00000000
        should be: 04030201
FAILURE: test #10910 at byte 0
        output   : 00000000
        should be: 040302f1
FAILURE: test #10910 at byte 1
        output   : 00000000
        should be: 040302f1
FAILURE: test #10910 at byte 2
        output   : 00000000
        should be: 040302f1
FAILURE: test #10910 at byte 3
        output   : 00000000
        should be: 040302f1
FAILURE: test #10911 at byte 0
        output   : 00000000
        should be: 040302f1
FAILURE: test #10911 at byte 1
        output   : 00000000
        should be: 040302f1
FAILURE: test #10911 at byte 2
        output   : 00000000
        should be: 040302f1
FAILURE: test #10911 at byte 3
        output   : 00000000
        should be: 040302f1
FAILURE: test #10920 at byte 0
        output   : 00000000
        should be: f4030201
FAILURE: test #10920 at byte 1
        output   : 00000000
        should be: f4030201
FAILURE: test #10920 at byte 2
        output   : 00000000
        should be: f4030201
FAILURE: test #10920 at byte 3
        output   : 00000000
        should be: f4030201
FAILURE: test #10921 at byte 0
        output   : 00000000
        should be: f4030201
FAILURE: test #10921 at byte 1
        output   : 00000000
        should be: f4030201
FAILURE: test #10921 at byte 2
        output   : 00000000
        should be: f4030201
FAILURE: test #10921 at byte 3
        output   : 00000000
        should be: f4030201
FAIL: pack_test
PASS: unpack_test
/bin/sh: line 4: 23183 Speicherzugriffsfehler  ${dir}$tst
FAIL: uri_test
=====================================
2 of 8 tests failed
Please report to gnet@gnetlibrary.org
=====================================
make[2]: *** [check-TESTS] Fehler 1
make[2]: Leaving directory `/var/tmp/portage/net-libs/gnet-2.0.7/work/gnet-2.0.7/tests'
make[1]: *** [check-am] Fehler 2
make[1]: Leaving directory `/var/tmp/portage/net-libs/gnet-2.0.7/work/gnet-2.0.7/tests'
make: *** [check-recursive] Fehler 1


Someting about my System:

 # emerge --info
Portage 2.1.3.9 (default-linux/amd64/2007.0/desktop, gcc-4.1.2, glibc-2.5-r4, 2.6.22-gentoo-r5 x86_64)
=================================================================
System uname: 2.6.22-gentoo-r5 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 3800+
Timestamp of tree: Tue, 25 Sep 2007 19:50:01 +0000
ccache version 2.4 [enabled]
app-shells/bash:     3.2_p17
dev-java/java-config: 1.3.7, 2.0.33-r1
dev-lang/python:     2.4.4-r4
dev-python/pycrypto: 2.0.1-r6
dev-util/ccache:     2.4-r7
sys-apps/baselayout: 1.12.9-r2
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.61
sys-devel/automake:  1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10
sys-devel/binutils:  2.17-r1
sys-devel/gcc-config: 1.3.16
sys-devel/libtool:   1.5.24
virtual/os-headers:  2.6.21
ACCEPT_KEYWORDS="amd64"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=athlon64 -O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config"
CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/terminfo"
CXXFLAGS="-march=athlon64 -O2 -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="buildpkg ccache distlocks metada-tatransfer metadata-transfer nostrip sandbox sfperms strict test unmerge-orphans userfetch"
GENTOO_MIRRORS="ftp://ftp.tu-clausthal.de/pub/linux/gentoo/ ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror/ ftp://linux.rz.ruhr-uni-bochum.de/gentoo-mirror/ http://ftp.uni-erlangen.de/pub/mirrors/gentoo ftp://ftp.uni-erlangen.de/pub/mirrors/gentoo ftp://ftp.join.uni-muenster.de/pub/linux/distributions/gentoo ftp://ftp.wh2.tu-dresden.de/pub/mirrors/gentoo http://mirrors.sec.informatik.tu-darmstadt.de/gentoo/ http://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ ftp://ftp.gentoo.mesh-solutions.com/gentoo/ http://pandemonium.tiscali.de/pub/gentoo/ ftp://pandemonium.tiscali.de/pub/gentoo/ http://gentoo.mneisen.org/ ftp://ftp.mneisen.org/gentoo "
LC_ALL="de_DE.UTF-8"
LINGUAS="de en"
MAKEOPTS="-j3"
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage"
USE="X acl acpi alsa amd64 arts berkdb bitmap-fonts cairo cdr cli cracklib crypt cups dbus dri dvd dvdr dvdread eds emboss encode esd evo fam firefox fortran gdbm gif gnome gpm gstreamer gtk hal iconv ipv6 isdnlog jpeg kde kerberos ldap mad midi mikmod mmx mp3 mpeg mudflap ncurses nls nptl nptlonly nvidia ogg opengl openmp oss pam pcre pdf perl png pppd python qt3 qt3support qt4 quicktime readline reflection sdl session slang spell spl sse sse2 ssl svg tcpd test tetex tiff truetype truetype-fonts type1-fonts unicode vorbis xml xorg xv zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="de en" USERLAND="GNU" VIDEO_CARDS="apm ark chips cirrus cyrix dummy fbdev glint i128 i810 mach64 mga neomagic nv r128 radeon rendition s3 s3virge savage siliconmotion sis sisusb tdfx tga trident tseng v4l vesa vga via vmware voodoo"
Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY

Have you (either/both of you) tried GNet from SVN trunk by any chance? (You should probably install the 'check' unit test framework before you do)

Christian: I'm fairly sure that your problems are fixed in SVN trunk.

Dustin: not sure why you get this.  Could just be that you don't get a redirect because of your location, or something that has been fixed in SVN.  If you could try SVN, that'd be great.

I checked out latest (446) revision from svn but I did not manage to build it because the configure script is missing. Could you please point me to what I have to do additionally?

Thanks.

> I checked out latest (446) revision from svn but I did not manage to build it
> because the configure script is missing. Could you please point me to what I
> have to do additionally?

There should be an autogen.sh script which you need to run in order to create the configure script.  You will need to have the usual auto* tools like automake/autoconf/libtool installed for this to work.

Thanks for trying!

Okay. I compiled svn 446 and tests still fail there. Here's the output:

make  check-TESTS
make[3]: Entering directory `/var/tmp/portage/net-libs/gnet-9999/work/gnet/tests/check'
Running suite(s): GConnHttp
Getting http://www.google.com ... ok, received 3201 bytes.
Getting http://www.google.co.uk ... ok, received 3254 bytes.
Getting http://www.google.de ... ok, received 3191 bytes.
Getting http://www.google.fr ... ok, received 3142 bytes.
Getting http://www.google.es ... ok, received 3790 bytes.
Getting http://www.gnome.org ... ok, received 5160 bytes.
Getting http://www.amazon.com ... ok, received 140695 bytes.
Getting http://sf.net ... ok, received 24785 bytes.
Getting (async) 'http://non-exist.ant' ... done, received 0 bytes.
Getting (async) 'http://www.google.com' ... done, received 3201 bytes.
Getting (async) 'http://www.google.co.uk' ... done, received 3254 bytes.
Getting (async) 'http://www.google.de' ... done, received 3201 bytes.
Getting (async) 'http://www.google.fr' ... done, received 3132 bytes.
Getting (async) 'http://www.google.es' ... done, received 3790 bytes.
gnet_http_get http://www.gnetlibrary.org/src/ ... done - buflen = 8182, code = 200
gnet_http_get http://www.heise.de ... done - buflen = 39545, code = 200
Getting binary file http://www.gnetlibrary.org/gnet.png ... ok, received 11230 bytes.
PNG image width x height = 500 x 100
80%: Checks: 5, Failures: 1, Errors: 0
gnet/gnetconnhttp.c:330:F:connhttp:test_conn_http_post:0: Assertion 'gnet_conn_http_run (http, http_dbg_callback, postdata)' failed
FAIL: gnet/gnetconnhttp
Running suite(s): GTcpSocket
............140 attempts
100%: Checks: 1, Failures: 0, Errors: 0
PASS: gnet/gnettcpsocket
Running suite(s): GNetABI
No structure size list was generated for this architecture.
Run with GNET_ABI environment variable set to output header.
100%: Checks: 1, Failures: 0, Errors: 0
PASS: gnet/gnetabi
Running suite(s): GNetBase64
100%: Checks: 2, Failures: 0, Errors: 0
PASS: gnet/gnetbase64
Running suite(s): GNetHashes
100%: Checks: 2, Failures: 0, Errors: 0
PASS: gnet/gnethash
Running suite(s): GInetAddr
100%: Checks: 5, Failures: 0, Errors: 0
PASS: gnet/gnetinetaddr
Running suite(s): GNetIPv6
GNet IPv6 default policy: GIPV6_POLICY_IPV4_ONLY
100%: Checks: 1, Failures: 0, Errors: 0
PASS: gnet/gnetipv6
Running suite(s): GNetPacking
100%: Checks: 6, Failures: 0, Errors: 0
PASS: gnet/gnetpack
Running suite(s): GNetUnpacking
100%: Checks: 5, Failures: 0, Errors: 0
PASS: gnet/gnetunpack
Running suite(s): GURI
100%: Checks: 3, Failures: 0, Errors: 0
PASS: gnet/gneturi
=====================================
1 of 10 tests failed
Please report to gnet@gnetlibrary.org
=====================================
make[3]: *** [check-TESTS] Error 1
make[3]: Leaving directory `/var/tmp/portage/net-libs/gnet-9999/work/gnet/tests/check'
make[2]: *** [check-am] Error 2
make[2]: Leaving directory `/var/tmp/portage/net-libs/gnet-9999/work/gnet/tests/check'
make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory `/var/tmp/portage/net-libs/gnet-9999/work/gnet/tests'
make: *** [check-recursive] Error 1

Could you do this:

 $ cd tests/check/
 $ GNET_DEBUG=1 make gnet/gnetconnhttp.check 2>&1 | tee dbg.log

and attach the dbg.log file to this bug report?

Created attachment 97059 [details]
log of debug output of test suite

As requested.

Thanks for that. Not sure what's going on there though.  We don't seem to get a http response nor headers from the server (or are parsing them wrongly if we are).

Could you run this from the tests/check directory

 $ strace -s 99999 -f -e trace=read,write gnet/gnetconnhttp 2>dbg.log

and then attach the dbg.log file?

Hopefully that will shed some light on what's going on.

Created attachment 97222 [details]
Requested log from strace

Hope this helps to track the bug.

Thanks a lot for the log!  However, according to the log, all the tests pass fine now, and the reponse also looks ok - very puzzling :)

But if you run it without the strace it fails again?

Maybe you could install valgrind, re-run ./configure and then try

  $ cd tests/check/
  $ make gnet/gnetconnhttp.valgrind 

to see if that brings up anything unusual?  (There will be a file called 'valgrind.log' in the directory afterwards if anything did come up)

Well...
You are right. The tests pass now. I don't know what caused this. In the meantime, I've updated a few packages on my machine. I cannot reproduce the failure anymore.

So that's good news. But maybe others still are hit by this.
Tests pass now only with CVS version and not 2.0.7, where I get still the same failure.

Should this bug be closed or do you want me to post the list of updated packages for further investigation?

Thanks for your help.

BR,
Dustin

> Should this bug be closed or do you want me to post the list of updated
> packages for further investigation?

If you know which packages you updated, a list would be very helpful, just in case someone runs into the same thing in future.  If you have old and new version numbers, that would even be better.

Thanks for following up on this and providing all the logs!

Created attachment 97235 [details]
strace output with failing test

Well...
I check today again and the test fails now again so I re-open this bug again.

Yesterday, when I was trying to produce the requested output, I was at home in my private network. Today, I am at work behind a more restrictive firewall. Could this be connected to the failure?

BR,
Dustin

It could be related.  Maybe your work firewall makes things go through a transparent proxy or something, which causes things to come out differently, or maybe it's just the constellation of the stars, who knows.

I can't really spot anything unusual in the strace output, but it doesn't tell me the chunking in which data comes in.

Could you do the following:

 - add the following lines to gnet/src/conn-http.c at the very
   beginning of the gnet_conn_http_conn_got_data() function around
   line 1150:

       {
           gint i;

           g_print ("DATA READ: %4u ", (guint) len);
           for (i = 0; i < len; ++i)
              g_print ("%c", data[i]);
            g_print ("\n");
       }

 - edit gnet/tests/check/gnet/gnetconnhttp.c like this: at the very
   bottom, add an if (0) in front of every 'tcase_add_test ...' line
   except the one with test_conn_http_post in it.  This is not
   absolutely required, but reduces the noise a bit :)

 - run 'make' in the top-level directory

 - cd tests/check/

 - run  'GNET_DEBUG=1 make gnet/gnetconnhttp.check 2>&1 | tee post.log'
   and attach the post.log file

Hopefully that gives me more to work with. Thanks for hanging in there :)

Created attachment 97242 [details]
Hopefully more verbose output

Hope this helps to clarify what's going on.

PS: Could you next time please attach a patch? This will help to reduce typos and ensures that everything is changed like you prefer. Thanks.

Thanks!

Does this fix it:

 2007-10-16  Tim-Philipp Müller  <tim at centricular dot net>

        * NEWS:
        * src/conn-http.c:
          Fix parsing of POST method response if the server returns
          optional headers after the initial 100-Continue response.
          Should fix #459895.

        * tests/check/gnet/gnetconnhttp.c:
          Add unit test for the above.

?

I checked out the newest svn revision and that specific test does not fail anymore. That's good news. Good work!

However, later on in the test suite (the echoserver tests), tests are very shaky. Sometimes they pass, sometimes not. Looks to me like a timeout(?) problem.

Do you want to investigate this issue? Can I provide some information for this? And do you prefer to have this discussed in this bug or should I open a new bug?

BR,
Dustin

> I checked out the newest svn revision and that specific test does not fail
> anymore. That's good news. Good work!

Yay! Thanks for all your help tracking this down.

 
> However, later on in the test suite (the echoserver tests), tests are very
> shaky. Sometimes they pass, sometimes not. Looks to me like a timeout(?)
> problem.
> 
> Do you want to investigate this issue? Can I provide some information for 
> this?
> And do you prefer to have this discussed in this bug or should I open a new
> bug?

Please file a new bug, thanks.