From morgant at makkintosshu.com  Mon Aug  3 12:41:30 2009
From: morgant at makkintosshu.com (Morgan Aldridge)
Date: Mon, 3 Aug 2009 12:41:30 -0400
Subject: [sysmon-help] Frequently failing Sysmon ping tests...
In-Reply-To: <fbf0108d0908030940g44894809j9b4c30ce0cbe9de1@mail.gmail.com>
References: <fbf0108d0907310447v5de17f73t8a7329101cc8e72@mail.gmail.com>
	<fbf0108d0907310516nc009d91jfc1ce99e0d872079@mail.gmail.com>
	<154DCED3-6288-43FC-BA18-344EEEBEE1A3@geeklair.net>
	<fbf0108d0907310757g1db67487q685a5aac74365de8@mail.gmail.com>
	<FDADDB9B-E086-4FFF-8911-EC2964B0BFC0@geeklair.net>
	<fbf0108d0907310848l424b5830o3905632ae997bb12@mail.gmail.com>
	<F39A412A-178F-4603-8CB9-590B7A4FD19F@geeklair.net>
	<fbf0108d0908030940g44894809j9b4c30ce0cbe9de1@mail.gmail.com>
Message-ID: <fbf0108d0908030941h4c5ffbcel64eb4c10215b1025@mail.gmail.com>

On Mon, Aug 3, 2009 at 12:40 PM, Morgan
Aldridge<morgant at makkintosshu.com> wrote:
>
> Could it have anything to do with 'buffer' having a length of 1024?
> None of the lines in the source of the page being requested appear to
> have even 255 chars, let alone 1024, but I haven't looked at
> getline_tcp() to see how it determines what one line is.

To continue my thinking outloud...

I took a peek at getline_tcp() in talktcp.c and have a question about
the following part of it:

   strncat(buffer, &buf, 1);
   if (strlen(buffer) > 200)
   {
       return 0;
   }

Shouldn't that conditional statement be something more like the following?

   if (strlen(buffer) >= sizeof(buffer))

I ask this because the buffer that service_test_www() (from http.c)
sends to getline_tcp() is an array of 1024 characters, so isn't
getline_tcp() returning if the length of the string stored in the
buffer exceeds 200 characters, therefore only utilizing about 20% of
the buffer?

Granted, service_test_www() doesn't seem to check the length of buffer
before sending it to print_err() and I didn't immediately see anything
else in getline_tcp() that could cause the out-of-bounds read. Any
other tips so I can get debugging working properly and try to find the
main issue?

Morgan Aldridge
---
morgant at makkintosshu.com
http://www.makkintosshu.com/

From morgant at makkintosshu.com  Mon Aug  3 12:40:26 2009
From: morgant at makkintosshu.com (Morgan Aldridge)
Date: Mon, 3 Aug 2009 12:40:26 -0400
Subject: [sysmon-help] Frequently failing Sysmon ping tests...
In-Reply-To: <F39A412A-178F-4603-8CB9-590B7A4FD19F@geeklair.net>
References: <fbf0108d0907310447v5de17f73t8a7329101cc8e72@mail.gmail.com>
	<fbf0108d0907310516nc009d91jfc1ce99e0d872079@mail.gmail.com>
	<154DCED3-6288-43FC-BA18-344EEEBEE1A3@geeklair.net>
	<fbf0108d0907310757g1db67487q685a5aac74365de8@mail.gmail.com>
	<FDADDB9B-E086-4FFF-8911-EC2964B0BFC0@geeklair.net>
	<fbf0108d0907310848l424b5830o3905632ae997bb12@mail.gmail.com>
	<F39A412A-178F-4603-8CB9-590B7A4FD19F@geeklair.net>
Message-ID: <fbf0108d0908030940g44894809j9b4c30ce0cbe9de1@mail.gmail.com>

On Fri, Jul 31, 2009 at 11:53 AM, Daniel J. Luke<dluke at geeklair.net> wrote:
>
> On Jul 31, 2009, at 11:48 AM, Morgan Aldridge wrote:
>
>> I may try vsnprintf() myself if I can't get much headway any other way.
>
> If you try it and it fixes the crash for you, I'll check in the change (and
> see if I can irritate jared while he's on vacation ;-) ).

Excellent, I didn't know anyone except jared had cvs access. :)

Unfortunately,, using vsnprintf() didn't seem to do the trick:

bash-3.2$ diff lib.c.old lib.c
675c675
< 	vsprintf (buffer, fmt, ap);
---
> 	vsnprintf (buffer, sizeof(buffer), fmt, ap);

Still gives me the same crash reports.

I don't see anything wrong with fprintf() call in syslogmsg(), so I'd
assume it's something to do with the arguments being passed to
print_err() by service_test_www().

The following are the debug lines immediately before the crash
pertaining to the last test:

Aug  3 07:54:56 bento org.sysmon.sysmond[51596]: sysmond: 07:54:56
service_this:Servicing entry in queue of bento.makkintosshu.com:www
Aug  3 07:54:56 bento org.sysmon.sysmond[51596]: sysmond: 07:54:56
http.c:Got :   <TD align=right>DL Rate<TD align=right>UL Rate:
Searching for :CTCS Version 1.4.1:
Aug  3 07:54:56 bento org.sysmon.sysmond[51596]: sysmond: 07:54:56
http.c:Got :   <TD align=right>DL Total<TD align=right>UL Total:
Searching for :CTCS Version 1.4.1:
Aug  3 07:54:56 bento org.sysmon.sysmond[51596]: sysmond: 07:54:56
http.c:Got :   <TD align=right>Limit D/U</TR>: Searching for :CTCS
Version 1.4.1:
Aug  3 07:54:56 bento org.sysmon.sysmond[51596]: sysmond: 07:54:56
http.c:Got :<TR bgcolor="#ccccff"><TD colspan=5><A
HREF="/torrent/-CD0303-u0xB94F21EDF3472D60A568C8"><B>/Library/BitTorrent/Newton_Museum_.dmg_file.4006452.TPB.torrent</B></A>:
Searching for :CTCS Version 1.4.1:
Aug  3 07:54:56 bento org.sysmon.sysmond[51596]: sysmond: 07:54:56
http.c:Got :   <TD colspan=3 align=right>Sun Aug  2 02:02:29
2009</TR>: Searching for :CTCS Version 1.4.1:
Aug  3 07:54:56 bento org.sysmon.sysmond[51596]: sysmond: 07:54:56
about to abort and dump core (i think in /)

I'd assume it has to do with the following lines in the 'WWW_SENT_REQUEST' case:

    getline_tcp(here->filedes, buffer);
    times_read++;
    if (debug)
        print_err(0, "http.c:Got :%s: Searching for :%s:", buffer,
here->checkent->url_t
ext);

Could it have anything to do with 'buffer' having a length of 1024?
None of the lines in the source of the page being requested appear to
have even 255 chars, let alone 1024, but I haven't looked at
getline_tcp() to see how it determines what one line is.

Morgan Aldridge
---
morgant at makkintosshu.com
http://www.makkintosshu.com/

From jared at puck.nether.net  Mon Aug  3 15:45:41 2009
From: jared at puck.nether.net (Jared Mauch)
Date: Mon, 3 Aug 2009 15:45:41 -0400
Subject: [sysmon-help] Frequently failing Sysmon ping tests...
In-Reply-To: <fbf0108d0908030941h4c5ffbcel64eb4c10215b1025@mail.gmail.com>
References: <fbf0108d0907310447v5de17f73t8a7329101cc8e72@mail.gmail.com>
	<fbf0108d0907310516nc009d91jfc1ce99e0d872079@mail.gmail.com>
	<154DCED3-6288-43FC-BA18-344EEEBEE1A3@geeklair.net>
	<fbf0108d0907310757g1db67487q685a5aac74365de8@mail.gmail.com>
	<FDADDB9B-E086-4FFF-8911-EC2964B0BFC0@geeklair.net>
	<fbf0108d0907310848l424b5830o3905632ae997bb12@mail.gmail.com>
	<F39A412A-178F-4603-8CB9-590B7A4FD19F@geeklair.net>
	<fbf0108d0908030940g44894809j9b4c30ce0cbe9de1@mail.gmail.com>
	<fbf0108d0908030941h4c5ffbcel64eb4c10215b1025@mail.gmail.com>
Message-ID: <07E86096-D0E6-423D-9549-50050DB877D8@puck.nether.net>

i should have decent network access sometime tomorrow. Will try to  
look at this.

Jared Mauch

On Aug 3, 2009, at 12:41 PM, Morgan Aldridge  
<morgant at makkintosshu.com> wrote:

> On Mon, Aug 3, 2009 at 12:40 PM, Morgan
> Aldridge<morgant at makkintosshu.com> wrote:
>>
>> Could it have anything to do with 'buffer' having a length of 1024?
>> None of the lines in the source of the page being requested appear to
>> have even 255 chars, let alone 1024, but I haven't looked at
>> getline_tcp() to see how it determines what one line is.
>
> To continue my thinking outloud...
>
> I took a peek at getline_tcp() in talktcp.c and have a question about
> the following part of it:
>
>   strncat(buffer, &buf, 1);
>   if (strlen(buffer) > 200)
>   {
>       return 0;
>   }
>
> Shouldn't that conditional statement be something more like the  
> following?
>
>   if (strlen(buffer) >= sizeof(buffer))
>
> I ask this because the buffer that service_test_www() (from http.c)
> sends to getline_tcp() is an array of 1024 characters, so isn't
> getline_tcp() returning if the length of the string stored in the
> buffer exceeds 200 characters, therefore only utilizing about 20% of
> the buffer?
>
> Granted, service_test_www() doesn't seem to check the length of buffer
> before sending it to print_err() and I didn't immediately see anything
> else in getline_tcp() that could cause the out-of-bounds read. Any
> other tips so I can get debugging working properly and try to find the
> main issue?
>
> Morgan Aldridge
> ---
> morgant at makkintosshu.com
> http://www.makkintosshu.com/
> _______________________________________________
> Sysmon-help mailing list
> Sysmon-help at puck.nether.net
> https://puck.nether.net/mailman/listinfo/sysmon-help

From morgant at makkintosshu.com  Mon Aug  3 16:44:24 2009
From: morgant at makkintosshu.com (Morgan Aldridge)
Date: Mon, 3 Aug 2009 16:44:24 -0400
Subject: [sysmon-help] Frequently failing Sysmon ping tests...
In-Reply-To: <AC26D934-8766-4BB0-94E7-C4BA4B37625F@geeklair.net>
References: <fbf0108d0907310447v5de17f73t8a7329101cc8e72@mail.gmail.com>
	<fbf0108d0907310516nc009d91jfc1ce99e0d872079@mail.gmail.com>
	<154DCED3-6288-43FC-BA18-344EEEBEE1A3@geeklair.net>
	<fbf0108d0907310757g1db67487q685a5aac74365de8@mail.gmail.com>
	<FDADDB9B-E086-4FFF-8911-EC2964B0BFC0@geeklair.net>
	<fbf0108d0907310848l424b5830o3905632ae997bb12@mail.gmail.com>
	<F39A412A-178F-4603-8CB9-590B7A4FD19F@geeklair.net>
	<fbf0108d0908030535g4ac0350ata06bcc0bc8c9156c@mail.gmail.com>
	<fbf0108d0908030938y6c75da21m3839a7384de6317b@mail.gmail.com>
	<AC26D934-8766-4BB0-94E7-C4BA4B37625F@geeklair.net>
Message-ID: <fbf0108d0908031344j6a62ddfdra58adf0f8b1b5850@mail.gmail.com>

On Mon, Aug 3, 2009 at 1:43 PM, Daniel J. Luke<dluke at geeklair.net> wrote:
>
> On Aug 3, 2009, at 12:38 PM, Morgan Aldridge wrote:
>>
>> Shouldn't that conditional statement be something more like the following?
>>
>> ? if (strlen(buffer) >= sizeof(buffer))
>
> well, it would be pretty bad if the size of the string in that buffer was
> bigger than the buffer ;-)

Haha, very true! :D

>> I ask this because the buffer that service_test_www() (from http.c)
>> sends to getline_tcp() is an array of 1024 characters, so isn't
>> getline_tcp() returning if the length of the string stored in the
>> buffer exceeds 200 characters, therefore only utilizing about 20% of
>> the buffer?
>
> yeah, I think there's probably some history where the buffers everywhere
> used to be ~ 256 characters long and jared must have gone and bumped some
> (but not all of them) to 1024

That was my assumption.

> just wasting memory shouldn't cause the crash, though.

For sure.

>> Granted, service_test_www() doesn't seem to check the length of buffer
>> before sending it to print_err() and I didn't immediately see anything
>> else in getline_tcp() that could cause the out-of-bounds read. Any
>> other tips so I can get debugging working properly and try to find the
>> main issue?
>
> If I were ambitious, I would try to get you to build a minimal config that
> exhibits the issue and get you to send it to me (or jared) so we could just
> track down the problem.

I'll definitely see what I can do in that department.

> I've been meaning to try out valgrind now that it supposedly works on Mac OS
> X - and it might be helpful in this case.
>
> Otherwise, there's always gdb (or even just adding a bunch of extra
> logging)...

I haven't used gdb in a long time, but I'll look up the documentation
and see how far I get.

Morgan Aldridge
---
morgant at makkintosshu.com
http://www.makkintosshu.com/

From morgant at makkintosshu.com  Mon Aug  3 16:46:21 2009
From: morgant at makkintosshu.com (Morgan Aldridge)
Date: Mon, 3 Aug 2009 16:46:21 -0400
Subject: [sysmon-help] Frequently failing Sysmon ping tests...
In-Reply-To: <07E86096-D0E6-423D-9549-50050DB877D8@puck.nether.net>
References: <fbf0108d0907310447v5de17f73t8a7329101cc8e72@mail.gmail.com>
	<fbf0108d0907310516nc009d91jfc1ce99e0d872079@mail.gmail.com>
	<154DCED3-6288-43FC-BA18-344EEEBEE1A3@geeklair.net>
	<fbf0108d0907310757g1db67487q685a5aac74365de8@mail.gmail.com>
	<FDADDB9B-E086-4FFF-8911-EC2964B0BFC0@geeklair.net>
	<fbf0108d0907310848l424b5830o3905632ae997bb12@mail.gmail.com>
	<F39A412A-178F-4603-8CB9-590B7A4FD19F@geeklair.net>
	<fbf0108d0908030940g44894809j9b4c30ce0cbe9de1@mail.gmail.com>
	<fbf0108d0908030941h4c5ffbcel64eb4c10215b1025@mail.gmail.com>
	<07E86096-D0E6-423D-9549-50050DB877D8@puck.nether.net>
Message-ID: <fbf0108d0908031346v1bdac07fif2ec9e399cc5f0c8@mail.gmail.com>

On Mon, Aug 3, 2009 at 3:45 PM, Jared Mauch<jared at puck.nether.net> wrote:
>
> i should have decent network access sometime tomorrow. Will try to look at
> this.

If you're really on vacation then don't worry about it at the moment.
I'll work through additional troubleshooting in the meantime.

Glad to know you're still out there and willing to take a peek at the
code, though.

Morgan Aldridge
---
morgant at makkintosshu.com
http://www.makkintosshu.com/