code logs -> 2013 -> Wed, 07 Aug 2013< code.20130806.log - code.20130808.log >
--- Log opened Wed Aug 07 00:00:47 2013
00:00 VirusJTG_ [VirusJTG@BAD19E.09A45B.582A63.5AE998] has joined #code
00:03 VirusJTG [VirusJTG@Nightstar-09c31e7a.sta.comporium.net] has quit [Ping timeout: 121 seconds]
00:05
<&McMartin>
Those of you who use PuTTY
00:05
<&McMartin>
PuTTY did a security update today, fixing four bugs in its crypto implementations.
00:06
<&McMartin>
Xires: did you post a sample somewhere? I must have pinged out while you did so, if you did
00:06
<&McMartin>
(I'm mostly seeing disconn/reconn messages in backscroll)
00:06
< Xires>
McMartin; I have not, yet
00:07
<&McMartin>
OK, just checking
00:07
<&McMartin>
When you do, nickping; I don't have this window up front often
00:08
< Xires>
understood
00:10 Karono [Karono@9C034E.4BE65E.E00AF8.FDA077] has joined #code
00:15 VirusJTG__ [VirusJTG@Nightstar-09c31e7a.sta.comporium.net] has joined #code
00:19 VirusJTG_ [VirusJTG@BAD19E.09A45B.582A63.5AE998] has quit [Ping timeout: 121 seconds]
00:20 * simon_ ignores joins/parts on most networks
00:43
<@Reiv>
Crypto is one of those places you really want to have bug free.
00:43
<&McMartin>
Yeeeees.
00:44
<&McMartin>
And this has also pointedly revealed that PuTTY uses its own implementations of the algorithms.
00:44
< Azash>
Now, now McMartin
00:44
< Azash>
That whole school of thought about not writing your own implementation is for the skittish
00:45
<&McMartin>
Well, it depends on how good it is~
00:46
<@Namegduf>
Does it?
00:47
<@Namegduf>
Or does it just embed a library which needed updating?
00:47
< Azash>
Still
00:47
<@Namegduf>
That's pretty much how you do things on Windows.
00:47
< Azash>
Wouldn't those libraries be provided by the OS?
00:48
<@Namegduf>
No.
00:48
<@Namegduf>
Windows doesn't do package management.
00:48
<&McMartin>
Er
00:48
<@Namegduf>
Shared libraries are a bigger threat from some stupid old version sitting around and supplanting your fixed one than they are a solution.
00:48
<&McMartin>
It kind of does, but it tries hard to hide it~
00:48 * simon_ didn't actually read about the bugfixes in specific, but assumes that the *use* of crypto libraries might just as well go wrong as implementing them. I also suppose there are two opposing interests: using the same libraries everywhere to maximize the likelihood of finding bugs, and using different libraries to minimize the likelihood of everyone being struck at once.
00:48
< Azash>
I know that but I would've thought that it offered at least basic tools that got updated with the rest
00:48
<@Namegduf>
Only if you write in C#
00:49
<@Namegduf>
And even then there's good reasons to reach out to third party implementations
00:49
<&McMartin>
Yeah, the .NET runtime is in Windows Update but for some insane reason the MSVC runtimes are not.
00:49
< Azash>
I suppose the easiest way to find out is to see whether the bug affected all versions of PuTTy or select OSes
00:49
<&McMartin>
All versions, but PuTTY is very, very windows specific even though a Unix version exists.
00:49
< Azash>
Ah
00:50
<&McMartin>
(Also, um, I'd have to check, but it's entirely possible Windows *didn't* have an exposed crypto library at the time of PuTTY's release)
00:50
<@Namegduf>
Or it doesn't have the right algorithms in.
00:50
<&McMartin>
Also possible; I recall XP required you to put in special packs for algos to get around export controls.
00:50
< Azash>
re. rolling your own, a crypto library is one of those "fun and informative to implement but never use it for anything" things
00:51
<@Namegduf>
It needs stuff that exactly matches what SSH servers routinely have.
00:51
< Azash>
Much like 3D engines and node.js services
00:51
<&McMartin>
Oh, um
00:51
<&McMartin>
PuTTY 0.45 was released in 1999.
00:52
<@Namegduf>
I think they get a pass for embedding a crypto library if that's what they did.
00:52
< Azash>
And even then it was software of a high calibre
00:52
< Xires>
McMartin; http://pastie.org/private/y6c69b4qseo5b0aqaag
00:52
<&McMartin>
Namegduf: Also, PuTTY is older than OpenSSH
00:53
<&McMartin>
That's a complete explanation in and of itself~
00:53
<@TheWatcher>
From the FAQ page: " PuTTY is almost completely composed of code written from scratch for PuTTY. The only code we share with OpenSSH is the detector for SSH-1 CRC compensation attacks, written by CORE SDI S.A; we share no code at all with OpenSSL."
00:53
<@Namegduf>
Before McMartin's last line, I would have been willing to say that was terrible
00:54 You're now known as TheWatcher[T-2]
00:55
<&McMartin>
Before I checked, me too~
00:55
< simon_>
also, sharing code with OpenSSL is good? ;-)
00:55
<&McMartin>
Xires: The part I find most suspicious is the phrase &pp->dat
00:55
<&McMartin>
I would write &(pp->dat[0]) there.
00:56
< Xires>
K
00:56
< Xires>
I'm astonished at how the older code worked..much of that was copied more or less verbatim
00:56
<&McMartin>
Or just pp->dat alone, but I usually only do that when passing to something like strcmp
00:56
<&McMartin>
Yeah, it's possible that this is actually getting burned by some kind of padding issue.
00:57
<&McMartin>
You may need some #pragma pack shenanigans here
00:59
< Xires>
McMartin; http://pastie.org/private/lrb15pxwzbrvihlokipcaq - I'd forgotten to include struct ip_t for the summary
01:00
<&McMartin>
OK, ip_t is gonna be *wildly* different between 32- and 64-bit versions
01:00
< simon_>
was it someone on here who linked to HTTPS having a vulnerability? http://www.kb.cert.org/vuls/id/987798
01:01
<&McMartin>
Xires: Do you happen to know if this stub code you wrote works on 32- and 64-bit?
01:01 Vornicus [vorn@ServerAdministrator.Nightstar.Net] has quit [[NS] Quit: Leaving]
01:02
< Xires>
McMartin; I've not compiled this piece by itself..only threw it together & ripped out anything that might violate my NDA
01:02
<&McMartin>
(In particular, if you're doing any casting of these values to things from a network source, that's going to be utterly disastrous on a machine with the wrong bit width unless you include directives like #pragma pack(1))
01:02
< Xires>
but the rest of the code does indeed compile both 32- & 64-bit
01:03
<&McMartin>
Compile, yes; *run* is the trick~
01:06
< Xires>
McMartin; runs on both 32- & 64-bit equally
01:06
< Xires>
all the same features work..all the same problems occur
01:07
<&McMartin>
Mmmm
01:07
< Xires>
neither is more or less stable and neither produces a problem that the other doesn't exhibit
01:07 * McMartin nods
01:07
<&McMartin>
OK
01:07
< Xires>
nor does either one work where the other doesn't
01:07
<&McMartin>
I think your best next move is to run your real code under valgrind
01:07
<&McMartin>
valgrind detects buffer blowouts as they occur
01:07
< Xires>
also, sizeof(ip_t) between 32- & 64-bit reports the same 20 bytes
01:08
< Xires>
valgrind & mudflap have not been helpful to me
01:08
< Xires>
and efence has been virtually useless
01:08
<&McMartin>
efence is stack-only and this is heap corruption of some kind, so that makes sents
01:08
<&McMartin>
*sense
01:09
<&McMartin>
Anyway
01:09 You're now known as TheWatcher[zZzZ]
01:10
<&McMartin>
The only way I can see this exploding in your face is if (a) struct pcap_pkthdr has a different packing discipline than pkt_t (unlikely)
01:10
< Xires>
McMartin; so it was ln#128 that you said would be better as &(pp->dat[0]) ?
01:10
<&McMartin>
Or if the "b" argument isn't at least 69 bytes long.
01:10
<&McMartin>
Yes.
01:10
<&McMartin>
The usage in #126 is what I would expect to see.
01:11
< Xires>
understood
01:12
<&McMartin>
It's possible that they're equivalent, but I don't trust C that far~
01:12
< Xires>
I understand
01:13
< Xires>
I saw them as equivalent but I'm kinda doubting everything right now
01:13
<&McMartin>
To be clear: The intent is to interpret the first N bytes of the "dat" stuff just copied in in line 126 as an ether_hdr_t?
01:14
<&McMartin>
And not to rip a pointer out of the first 4/8 bytes and use *that* as one?
01:16
<&McMartin>
(I hope it's the former; the latter is unpleasantry even to my twisted mind)
01:17
< Xires>
from my understanding of the code; the intent is, unfortunately, the latter
01:17
<&McMartin>
OK
01:17
<&McMartin>
My first reaction is "I don't actually believe you"
01:18
<&McMartin>
If the thing being memcpy'd in is an ether_hdr_t, that's evidence that the intent is the former
01:18
< Xires>
well, in this specific function, the code actually only appears to do reads, not writes
01:19
<&McMartin>
Right; I'm just counting levels of indirection here. The #126 usage is equivalent to C++'s reinterpret_cast<>.
01:19
<&McMartin>
And this kind of thing is the sort of place you'd use that
01:20
< Xires>
I think I'd prefer, just for clarity, to make the ipp variable 'const'
01:20
< Xires>
though, ipp isn't just a cast of pp->dat but pp->dat[14]
01:20
< Xires>
14 bytes into the dat structure
01:21
< Xires>
s/structure/buffer/
01:21 * McMartin nods
01:21
<&McMartin>
*that* operation is dangerous as Hell.
01:21
< Xires>
indeed
01:21
<&McMartin>
The safest way to handle that is not to count bytes, but to cast it to a properly organized structure and do field dereferences.
01:21
< Xires>
particularly since it's done with a calloc()'d parent buffer
01:21
<&McMartin>
That improves things slightly; calloc() is the one that properly memsets it to 0 before returning it, right?
01:22
< Xires>
only after the ipp pointer is established is data written to pp->dat[0]
01:22
<&McMartin>
As opposed to being Literally ANything
01:22
< Xires>
via the memcpy() on ln#126
01:22
< simon_>
McMartin, that's what I recall.
01:23 himi [fow035@Nightstar-5d05bada.internode.on.net] has quit [Ping timeout: 121 seconds]
01:23
<&McMartin>
Xires, the ipp init is fine
01:23
<&McMartin>
It's equivalent to pp->dat + sizeof(ether_hdr_t)
01:23
< Xires>
yes, as noted on ln#92, g_slice_alloc0() essentially does a calloc(), using memset() to clear the buffer before returning the pointer
01:24
<&McMartin>
Oh!
01:24
<&McMartin>
I know a good sanity check
01:24
<&McMartin>
After the *first* memcpy
01:24
<&McMartin>
check h and pp's corresponding fields, one by one
01:24
<&McMartin>
Make sure they match up
01:24
<&McMartin>
If there's some kind of structure layout glitch, they won't.
01:24
< Xires>
all of them?
01:25
< Xires>
is this something just for debug or are you suggesting it be in the release as well?
01:25
<&McMartin>
Just for debug
01:25
<&McMartin>
If you get "impossible" answers, that means you should probably start dumping the various offsets of all the fields to see what's changing
01:25
< Xires>
K..just a note; this is meant for packet capture code on 10 Gbit lines so I'm trying to keep expensive operations to a minimum, if possible
01:26
<&McMartin>
Right
01:26
<&McMartin>
This is code for determining "will this *ever* work"
01:26
< Xires>
well, in gdb, I do check that pp->hdr & h match
01:26
<&McMartin>
If you were to deploy it you'd actually put it as a test module outside of the core code.
01:27
< Xires>
though, not at every iteration
01:27 RichyB [RichyB@D553D1.68E9F7.02BB7C.3AF784] has quit [[NS] Quit: Gone.]
01:27
<&McMartin>
The *really* important value here is caplen
01:28
<&McMartin>
caplen should be the minimum of snap (69) or h->caplen
01:29
< Xires>
and check that the strlen(b) >= 69?
01:29
<&McMartin>
strlen looks for nulls, I don't know the problem domain well enough to know if that's the mechanism, but it may not be
01:29
<&McMartin>
It needs to be >= caplen, though, not 69
01:29
< Xires>
sz = strlen(b); snap = (sz < 69) ? sz : 69; ?
01:29
<&McMartin>
If caplen < 69, b only needs to be *that* long.
01:30 Derakon[AFK] is now known as Derakon
01:30 RichyB [RichyB@D553D1.68E9F7.02BB7C.3AF784] has joined #code
01:30
<&McMartin>
Also
01:30
<&McMartin>
Line 128 is just generally scary
01:31
<&McMartin>
Do you know if that branch is being taken?
01:31
<&McMartin>
And if so, if ipp is being properly adjusted
01:31
< Xires>
it is, occasionally, being taken
01:31
< Xires>
and it does appear that it is correctly increasing the pointer by 2 bytes
01:31
<&McMartin>
Good. I was pretty sure it would do that
01:32
<&McMartin>
The next question is if *ipp is full of nonsense or not
01:32
< Xires>
though I would like to get rid of that strict aliasing warning
01:32
<&McMartin>
I'm not immediately familiar with that warning; can you quote it?
01:33
<&McMartin>
(also for god's sake put the consequent on its own line)
01:33
<&McMartin>
(That will also let you breakpoint exactly when the branch is taken)
01:34
<&McMartin>
Oh right, also
01:34
<&McMartin>
is "b" data coming in off the wire, untransformed?
01:35 Karono_ [Karono@9C034E.4BE65E.E00AF8.FDA077] has joined #code
01:36
<&McMartin>
Because if so that sets off all my bitwidth alarm bells
01:36 Karono [Karono@9C034E.4BE65E.E00AF8.FDA077] has quit [NickServ (GHOST command used by Karono_)]
01:36 Karono_ is now known as Karono
01:36
<&McMartin>
(And would mean the problem will manifest as nonsense filling up the pkt_t over the course of lines 130-136)
01:36
< Xires>
McMartin; "warning: dereferencing type-punned pointer will break strict-aliasing rules"
01:36 * McMartin nods
01:37
< Xires>
yes, 'b' is a selection of bytes directly from the packet off the wire
01:37
<&McMartin>
OK, in order
01:37
<&McMartin>
I think you can eradicate that warning by replicating the logic from line 119 but with a + 2 at the end
01:38
< Xires>
K
01:38
<&McMartin>
Casting from raw data like that is very hazardous but if you're sufficiently strapped for speed you may have no choice but to do that instead of using custom marshallers
01:39
< Xires>
unfortunately, duplicating that logic does not eradicate the warning
01:39
<&McMartin>
Next step is to hand-disassemble b's contents (strlen *will not work* here, incidentally; you've got shorts so any short less than 256 will falsely trigger end-of-string) and compare it against *ipp at line 130.
01:39
<&McMartin>
Interesting.
01:41
< Xires>
'tis alright, I can deal with that later
01:41
< Xires>
more concerned with the other issues, ATM
01:41
<&McMartin>
...maybe not
01:41
<&McMartin>
Try compiling with -fno-strict-aliasing
01:42
<&McMartin>
I'm seeing some hints that this warning means "if you have -O2 or higher on, the compiler may produce incorrect code"
01:43 VirusJTG_ [VirusJTG@BAD19E.09A45B.582A63.5AE998] has joined #code
01:43
<&McMartin>
Another thing to attempt would be to replace the unsigned char with just a char, but that may be a gcc-specific hack
01:43
<&McMartin>
(-fno-strict-aliasing may seriously impact performance)
01:44
< Xires>
McMartin; okay, libpcap denotes that it sets the pcap_pkthdr.caplen to the size of b
01:44
< Xires>
or otherwise guarantees that pcap_pkthdr.caplen is the correct size of b
01:44
<&McMartin>
OK, that part is fine then
01:44
<&McMartin>
I'd move on to checking *ipp, at the point where the rest of the pkt_t is assigned from its values
01:45
<&McMartin>
If those offsets don't work out those'll get disastrous garbage
01:45
< Xires>
so the logic of using snap or caplen, whichever is smaller, should work
01:45
<&McMartin>
Excellent
01:45 VirusJTG__ [VirusJTG@Nightstar-09c31e7a.sta.comporium.net] has quit [Ping timeout: 121 seconds]
01:46
<&McMartin>
Anyway, that warning is apparently quite alarming from some searches on it
01:46
<&McMartin>
And I say this as someone who type-puns with great ruthlessness
01:46
<&McMartin>
And I don't get it in my own code -_-
01:46
<&McMartin>
(It might be worth replacing those instances of "unsigned char" with "char" in the structure definitions)
01:47
< Xires>
perhaps I should just create a new variable to point directly to pp->dat[0] and test from there?
01:47
<&McMartin>
Also worthwhile, but I expect that to match b precisely
01:47
< Xires>
I think the line is related to the the 'if' condition, not the ipp assignment
01:47
<&McMartin>
It's the interpretation starting at line 130 that's the problem.
01:47
<&McMartin>
Er
01:47
<&McMartin>
That I suspect may be the problem
01:49
<&McMartin>
The part that's interesting here is the line "it is always assumed that char* aliases other types"
01:49
<&McMartin>
I wonder if that means it is not true for unsigned char *.
01:49
<&McMartin>
(But that's also another reason to not have test and consequent on the same line)
01:51
<&McMartin>
See: http://stackoverflow.com/questions/98650/what-is-the-strict-aliasing-rule
01:51
<&McMartin>
This also includes links to other things that are likely to Be Problems for you at the end.
01:51
<&McMartin>
The code is explicitly dealing with endianness; packing is the part that worries me the most about what you've pasted.
01:52
< Xires>
indeed, endianness is handled in multiple different sections, in different ways
01:53
< Xires>
part of the reason for the cidr_t is to switch addresses to the correct endianness
01:53 * McMartin nods
01:53
<&McMartin>
That said, the link regarding packing is not true anymore~
01:53
<&McMartin>
http://gcc.gnu.org/onlinedocs/gcc/Structure_002dPacking-Pragmas.html
01:53
< Xires>
familiar w/ that link
01:53
<&McMartin>
k
01:54
<&McMartin>
I didn't see them used in the paste which would make 32- and 64-bit object files possibly behave very differently
01:55
<&McMartin>
http://cellperformance.beyond3d.com/articles/2006/06/understanding-strict-aliasi ng.html is also pretty good
01:56
< Xires>
does it help that this code is never expected to run on Windows?
01:56
<&McMartin>
At this level? I don't think so; this all looks pretty os-neutral
01:56
<&McMartin>
It might help if it's never expected to run on anything that isn't x86 or x86_64
01:57
< Xires>
that too
01:57
< Xires>
it will only ever be Linux x86[_64]
01:57 Karono [Karono@9C034E.4BE65E.E00AF8.FDA077] has quit [Ping timeout: 121 seconds]
01:58
<&McMartin>
Then that is unlikely to help much, I'm afraid >_>
01:58
<&McMartin>
Because the pain comes in the 32-64 hop, which will modify structure offsets
01:59
< Xires>
K
02:01
< Xires>
so, then, the aliasing warning is symptom of improper handling of the data, resulting in part of the behavior?
02:01
<&McMartin>
Possible but not guaranteed
02:01
<&McMartin>
It's an indication that you're doing something potentially non-portable
02:01
< Xires>
wouldn't that cause different errors to be found between the systems?
02:02
<&McMartin>
However! You only have two platforms you care about, so that solves that, more or less
02:02
<&McMartin>
Depends.
02:02
<&McMartin>
You're getting a report of "wild memory corruption"
02:02 Karono [Karono@9C034E.4BE65E.E00AF8.FDA077] has joined #code
02:02
<&McMartin>
If it reaches that point by different ways, then that doesn't really change the symptom
02:02
< Xires>
yes
02:02
< Xires>
things break that normally shouldn't break
02:02
< Xires>
that have no reason for breaking
02:02
<&McMartin>
Does it break for both 32 and 64 bit or just for 64?
02:02 Karono [Karono@9C034E.4BE65E.E00AF8.FDA077] has quit [Connection reset by peer]
02:03 Karono [Karono@9C034E.4BE65E.E00AF8.FDA077] has joined #code
02:03
< Xires>
wild malloc() errors that crop up here & there causing anything from SIGSEGV to SIGABRT
02:03
< Xires>
both
02:03
< Xires>
both break in the same [numerous] places
02:03
< Xires>
with the same reasonings
02:03
< Xires>
with the same amount of randomness
02:04 Karono [Karono@9C034E.4BE65E.E00AF8.FDA077] has quit [Connection reset by peer]
02:04
< Xires>
sometimes the process will crash at the end of the hour..other times it'll run for 8 hours without a hitch and then die
02:04 * McMartin nods
02:05
<&McMartin>
If you're sure this is the source, I'd start putting in paranoia checks to make sure that values haven't changed mysteriously somehow
02:05
< Xires>
sometimes it crashes when calling free() to free a correctly malloc()'d buffer in something completely unrelated
02:05
<&McMartin>
If it's failing *inside malloc* that may be a sign of a double free()
02:06
<&McMartin>
Which will corrupt the arena
02:11 VirusJTG [VirusJTG@Nightstar-09c31e7a.sta.comporium.net] has joined #code
02:14 Reiv [NSwebIRC@Nightstar-95746c1f.kinect.net.nz] has quit [Ping timeout: 121 seconds]
02:15 VirusJTG_ [VirusJTG@BAD19E.09A45B.582A63.5AE998] has quit [Ping timeout: 121 seconds]
02:15
<&McMartin>
"The last member of a structure with more than one named member may have incomplete array type; such a structure shall not be a member of a structure or an element of an array."
02:15 Reiv [NSwebIRC@Nightstar-95746c1f.kinect.net.nz] has joined #code
02:15 mode/#code [+o Reiv] by ChanServ
02:15
< Xires>
McMartin; alright, I removed the strict-aliasing warning
02:15
<&McMartin>
If the code you're looking at has every worked, anywhere, ever, the dat field is not your problem
02:16
<&McMartin>
Oho? How'd you manage it?
02:17
< Xires>
ether_hdr_t *eh = (ether_hdr_t) &(pp->dat[0]); ip_t *ipp = (ip_t*) ((unsigned char*) eh + sizeof(ether_hdr_t));
02:18
<&McMartin>
OK, that looks good
02:19
<&McMartin>
What is the change that caused everything to start breaking? I got the impression this was a port.
02:19
<&McMartin>
Was it shifting to a new glibc?
02:19
< Xires>
then later, if (eh->ether_type == ETHERTYPE_8021Q) ipp = (ip_t*) ((unsigned char*) ipp + 2);
02:19
< Xires>
not glibc, glib2..different things
02:19
<&McMartin>
Aha, OK
02:20
< Xires>
glibc is the C library implementation that you're probably familiar with..glib2 is a utility API collection to help w/ portability & what-not
02:21
< Xires>
glib2 is what gtk uses to be architecture & platform-independent, basically
02:21
< Xires>
or, rather..not "independent"
02:21
< Xires>
but...I think you get the meaning
02:22
<&McMartin>
Right right
02:22
<&McMartin>
I misread or misremembered what you'd said
02:22
<&McMartin>
If it were a new libc, then malloc or free themselves might have changed
02:23
<&McMartin>
I wonder if glib2 has new invariants that are being violated somehow
02:23
<&McMartin>
Other than that, I'm tapped out. Sorry. =(
02:24
<&McMartin>
All I can say is that this part of the code looks pretty clean
02:24
< Xires>
well, that's delightful
02:25 * McMartin has no experience with glib2
02:26
<&McMartin>
As a fellow C/C++ programmer, sadface highfive for "bummer, this code works"
02:26
< Xires>
many thanks
02:27
< Xires>
glib2 is stable enough that I can reliably say that it is EXTREMELY unlikely to be a fault in glib2
02:27
< Xires>
and most of the stuff I'm using is easily broken down
02:28 Derakon is now known as Derakon[AFK]
02:31 Karono [Karono@9C034E.4BE65E.E00AF8.FDA077] has joined #code
02:31
<&McMartin>
Right
02:31
<&McMartin>
I didn't mean to imply "bug in glib2"
02:32
<&McMartin>
I meant more along the lines of "bug in your code that uses glib2, of the form 'causes undefined behavior'"
02:32
< Xires>
understood
02:32
<&McMartin>
That happened to be harmless in the old version but corrupts the heap in the new one
02:32
<&McMartin>
In my (limited, since the universe here is gigantic) experience that's most often caused by freeing the same pointer twice
02:33 Vorntastic [Vorn@Nightstar-5f5c5c2a.sub-70-211-2.myvzw.com] has joined #code
02:39 himi [fow035@Nightstar-5d05bada.internode.on.net] has joined #code
02:39 mode/#code [+o himi] by ChanServ
02:41
< Xires>
McMartin; looking at the code as posted..
02:43
< Xires>
sorry for delay, wife going crazy
02:43
<&McMartin>
No worries
02:43
< Xires>
anywho..with the code as posted can you tell me the correct size to free?
02:44
<&McMartin>
free doesn't require a size
02:44
<&McMartin>
It pulls it out of some metadata
02:44
< Xires>
g_slice_free1() does
02:44
<&McMartin>
oho
02:44
< Xires>
void g_slice_free1 (gsize block_size,
02:44
< Xires>
gpointer mem_block);
02:44
<&McMartin>
Eek
02:44
<&McMartin>
That's above my pay grade, I fear
02:44
<&McMartin>
I've never used that library, so I do not know
02:45
< Xires>
are you familiar with slab allocator?
02:45
<&McMartin>
Yes; written a few in my day
02:45
<&McMartin>
But that doesn't mean I know what the requirements are for this particular implementation
02:45
< Xires>
that's fine, I can explain enough of it..unless you've no interest
02:46
< Xires>
I've taken up quite a bit of your time..I'm thankful for all the advice & direction that you've provided
02:47
<&McMartin>
I'm kinda curious, but my guess is "that value has to be the same as the one you pass to the allocator"
02:47
< Xires>
'tis what I figured..wanted to make sure that nothing in mkpp() was changing that
02:47
< Xires>
I really wouldn't think so
02:48
<&McMartin>
Yeah, me either
02:48
<&McMartin>
Ugh, if it's slab does it not accept arbitrary values for block_size
02:51
< Xires>
well, it's allocated with (sizeof(pkt_t) + 1542) and freed as g_slice_free1((sizeof(pkt_t) + 1542), pp);
02:51
< Xires>
so same size allocation & free
02:51 * McMartin nods
02:52
<&McMartin>
I bet that's why valgrind is useless
02:52
< Xires>
quite possibly
02:52
< Xires>
hadn't thought of it 'til just a moment ago
02:52
<&McMartin>
I worry about double-free
02:52
<&McMartin>
slab allocators tend to recycle memory without actually free() ing it
02:52
< Xires>
indeed
02:52
<&McMartin>
Ha ha, oh man, that would be evil on a stick
02:53
<&McMartin>
You could #define away the slice operations to make them truly be calloc and free, and then valgrind *that*
02:53
< Xires>
I'll check to make sure that I don't free a section, like pp->dat, and then free pp later
02:53
< Xires>
glib2 allows you to essentially bypass the slab allocator via environment variable
02:53
< Xires>
G_SLICE=always-malloc
02:53
< Xires>
just uses malloc()
02:54
<&McMartin>
Eep
02:54
< Xires>
and g_slice_alloc0() will continue to memset to 0
02:54
<&McMartin>
If you free a section that isn't the top that might break the shit out of things
02:54
<&McMartin>
(Maybe not if the slab allocator is cunning)
02:54
< Xires>
indeed
02:54
< Xires>
ah, I remember why I suspected mkpp...
02:54
<&McMartin>
But I'm pretty sure the rule with malloc and free is that you only get to free things returned by malloc, exactly, and that exactly once.
02:55
<&McMartin>
If you don't do that, subsequent calls to malloc may fail horribly
02:55 Derakon[AFK] is now known as Derakon
02:55
< Xires>
running in gdb w/ mudflap, I see lots of issues where the calling function, the pcap_handler function, is denoted as having a 'violation'(thousands of them) on the line calling mkpp
02:55 ToxicFrog [ToxicFrog@4CA975.D980A3.0E5445.043306] has quit [[NS] Quit: ZNC - http://znc.in]
02:55
<&McMartin>
Aha
02:56
< Xires>
"nearby object 1: checked region begins 2201B after and ends 2204B after" "nearby object 2: checked region begins 528B before and ends 525B before"
02:56 ToxicFrog [ToxicFrog@4CA975.D980A3.0E5445.043306] has joined #code
02:56 mode/#code [+ao ToxicFrog ToxicFrog] by ChanServ
02:56
<&McMartin>
Hrm.
02:57
<&McMartin>
Yeah, I've never used mudflap either, I fear I can't interpret that
02:57
<&McMartin>
I wonder if it's somethign right before this call, though
02:59
< Xires>
while (hook) { [[\n]] hook->data = mkpp(hdr, b, cnt);
02:59
< Xires>
[[...]] to denote that section is not literally there
03:03
<&McMartin>
Mmm.
03:03
<&McMartin>
Yeah, I dunno
03:09
< Xires>
McMartin; np, ty again for all your guidance
03:09
<&McMartin>
you're welcome. Good luck.
03:11 ktemkin is now known as ktemkin[awol]
03:11
< Azash>
McMartin, more than meets the eye
03:11
< Azash>
Stackoverflow in disguise
03:12
<&McMartin>
Greybeard
03:13
<&McMartin>
I should probably actually spend an hour or two a week trying to answer things on SO
03:13
< Azash>
Good practice if nothing else
03:14
< Xires>
http://pastie.org/private/li3ficeflrypacipywhwg
03:14
< Xires>
erm, sorry
03:15
<@Reiv>
McMartin: For purposes?
03:16
<&McMartin>
noblesse oblige mostly >_>
03:16 * McMartin has been at this awhile now
03:34 Karono [Karono@9C034E.4BE65E.E00AF8.FDA077] has quit [Ping timeout: 121 seconds]
03:34 Karono_ [Karono@9C034E.4BE65E.E00AF8.FDA077] has joined #code
03:37 Karono_ is now known as Karono
03:40 VirusJTG [VirusJTG@Nightstar-09c31e7a.sta.comporium.net] has quit [Client closed the connection]
03:50 Harlow [Harlow@Nightstar-2dbe3d64.il.comcast.net] has joined #code
04:01 AnnoDomini [abudhabi@Nightstar-d410a3f0.adsl.inetia.pl] has quit [Ping timeout: 121 seconds]
04:05
< Xires>
McMartin; okay..so I thought you might be interested to know..after making just a few changes, particularly those to eliminate the strict-aliasing warnings, I have been waiting on the process to crash to see additional diagnostic information...
04:05
< Xires>
after lowering the timers to 1/20th of their original settings(which typically caused it to crash quit quickly)...it won't crash
04:06
< Xires>
I have it running on 4 VMs, twice on the host machine, on 3 remote VPS's, my work DevStack(6 times) + my laptop
04:06
< Xires>
not one of them has crashed
04:07
< Xires>
I'm afraid to say what I hope to be happening :-\
04:08 Karono [Karono@9C034E.4BE65E.E00AF8.FDA077] has quit [Client closed the connection]
04:08 Karono [Karono@9C034E.4BE65E.E00AF8.FDA077] has joined #code
04:15 Karono [Karono@9C034E.4BE65E.E00AF8.FDA077] has quit [Ping timeout: 121 seconds]
04:31
<&McMartin>
Heh
04:31
<&McMartin>
Hope springs eternal~
04:31
<&McMartin>
And there's a mechanism for what might be causing it, even!
04:32 Vornicus [vorn@ServerAdministrator.Nightstar.Net] has joined #code
04:32 mode/#code [+qo Vornicus Vornicus] by ChanServ
04:34 Kindamoody[zZz] is now known as Kindamoody
04:35 Vorntastic [Vorn@Nightstar-5f5c5c2a.sub-70-211-2.myvzw.com] has quit [[NS] Quit: Bye]
04:35 Vorntastic [Vorn@Nightstar-5f5c5c2a.sub-70-211-2.myvzw.com] has joined #code
04:35 Vorntastic [Vorn@Nightstar-5f5c5c2a.sub-70-211-2.myvzw.com] has quit [Client closed the connection]
05:04 Derakon is now known as Derakon[AFK]
05:18 Karono [Karono@9C034E.4BE65E.E00AF8.FDA077] has joined #code
05:20 Karono [Karono@9C034E.4BE65E.E00AF8.FDA077] has quit [Connection reset by peer]
05:20 Karono [Karono@9C034E.4BE65E.E00AF8.FDA077] has joined #code
05:22 Karono [Karono@9C034E.4BE65E.E00AF8.FDA077] has quit [Connection reset by peer]
06:47 Karono [Karono@Nightstar-13c26ed9.optusnet.com.au] has joined #code
08:02 ErikMesoy|sleep is now known as ErikMesoy
08:20 Kindamoody is now known as Kindamoody|afk
08:25 AverageJoe [evil1@Nightstar-4b668a07.ph.cox.net] has joined #code
08:26 celticminstrel [celticminst@Nightstar-ae361035.dsl.bell.ca] has quit [[NS] Quit: And lo! The computer falls into a deep sleep, to awake again some other day!]
09:09 You're now known as TheWatcher
09:11 AnnoDomini [abudhabi@Nightstar-d410a3f0.adsl.inetia.pl] has joined #code
09:27 Harlow [Harlow@Nightstar-2dbe3d64.il.comcast.net] has quit [[NS] Quit: Leaving]
10:25 AverageJoe [evil1@Nightstar-4b668a07.ph.cox.net] has quit [[NS] Quit: Leaving]
11:03
<@TheWatcher>
So, I have a system that is used to create articles that appear in RSS/Atom feeds. It also needs to be able to send full copies of these articles to users via a number of other methods (including email and moodle forum posts). I have been calling this latter functionality "Notifications", but I have been told that this is confusing as a couple of people think this means that the system is sending "go look at this link" emails rather than "here is
11:03
<@TheWatcher>
the whole article" emails. Any suggestions for an alternative name for these things?
11:05
<@TheWatcher>
"Messaging" might work, I guess, but feels wrong.
11:16
<@Tamber>
"Memos"?
11:21
<@TheWatcher>
Maybe, although that comes with some associated assumptions for content that don't really apply.
11:27
< Syka>
"newsfeed"?
11:30
<@TheWatcher>
That's what the rss/atom feeds are for, not the direct emails or moodle posts
11:31
<@TheWatcher>
It needs to be something that translates as "I am sending you a full copy of this article direct to you"
11:33
<@Tamber>
"Journal"? ...eh, actually, I dunno; that might be interpreted more in the "diary" sense.
11:33
<@TheWatcher>
Yeah, guaranteed
11:34
<~Vornicus>
"newsletter"
11:34
<@TheWatcher>
Nameclash, the system already produces newsletters.
11:35
<~Vornicus>
failonaut
11:36
<@Tamber>
"Goddamn, you people are hard to please. Here's your damn articles"?
11:36
<@TheWatcher>
Very, very tempting.
11:55
< Syka>
"articool 9000"
11:56
< Syka>
TheWatcher: maybe just "Full Articles" or something
12:05
<@gnolam>
"CC"?
12:14
<@Alek>
Mimeo
13:11 ktemkin[awol] is now known as ktemkin[work]
13:25
<&ToxicFrog>
Dispatches from the Front Lines
13:27
< Azash>
TheWatcher: "Delivery" ?
13:34
< Xires>
TheWatcher; I second Azash's suggestion..it seems most appropriate
13:35
<@TheWatcher>
I dunno, I kinda like ToxicFrog's. This is, after all, being used in a university >.>
13:39
< ErikMesoy>
"Readables"?
13:39
< ErikMesoy>
vaguely inspired by the "lunchables" snack
13:40 Chutzpah [Moltare@583787.FF2A18.190FE2.4D81A1] has quit [Client closed the connection]
13:41 Chutzpah [Moltare@583787.FF2A18.190FE2.4D81A1] has joined #code
13:58
< ktemkin[work]>
Subscriptions?
14:02 celticminstrel [celticminst@Nightstar-ae361035.dsl.bell.ca] has joined #code
14:02 mode/#code [+o celticminstrel] by ChanServ
14:02 Vornicus [vorn@ServerAdministrator.Nightstar.Net] has quit [[NS] Quit: Leaving]
14:03
<@Alek>
not bad.
14:04 celticminstrel [celticminst@Nightstar-ae361035.dsl.bell.ca] has quit [[NS] Quit: KABOOM! It seems that I have exploded. Please wait while I reinstall the universe.]
14:04 celticminstrel [celticminst@Nightstar-ae361035.dsl.bell.ca] has joined #code
14:04 mode/#code [+o celticminstrel] by ChanServ
14:05
<@TheWatcher>
Subscriptions doesn't work, as that implies that users have subscribed. Rather, these are being sent to groups of people determined using SECONDARY BLACK GRIMOIRE without intervention by the recipients
14:07
<@Alek>
Mandatory Subscriptions.
14:08 * Alek repeats,
14:08
<@Alek>
Mimeos
14:12
<@gnolam>
Article CC.
14:53
< ktemkin[work]>
A subscription without explicit subscribers could be described as a "broadcast".
14:53
< ktemkin[work]>
Though that's picked up other connotations.
14:57
<&McMartin>
If you're getting it from SECONDARY BLACK GRIMOIRE, surely this is code NIGHTMARE GREEN.
14:58
<&McMartin>
Or NIGHTMARE GREEN code. Whatever.
15:10
< Xires>
TheWatcher; "HEY!"? inspired by the fairy from some Zelda game
15:13
<&McMartin>
HEY LISTEN
15:14
< Xires>
McMartin; ty again for your assistance yesterday
15:14
<&McMartin>
No worries. Has it actually helped?
15:15
< Syka>
xires: Navi?
15:16
< Xires>
Syka; ci
15:17
<@TheWatcher>
I'd rather not be beaten to death by co-workers.
15:17
<&McMartin>
Hee
15:24
< Xires>
;-P
15:36
< ktemkin[work]>
And now I get to explain to our IT department's "unix expert" how to use the find command.
15:36
< ktemkin[work]>
Vunderbar.
15:36
<&McMartin>
ktemkin: So, do you use -exec grep or -print0 | xargs -0 grep
15:37
<&McMartin>
(The only argument even dumber than vi vs emacs)
15:38
< ktemkin[work]>
That's an argument?
15:39
<&McMartin>
Apparently people occasionally have strong preferences between the two!
15:39
< Azash>
http://www.kickstarter.com/projects/1523379957/oculus-rift-step-into-the-game/po sts/562211
15:40
<&McMartin>
I don't even remember why. Something to do with the way xargs breaks up arguments into individual commands or doesn't
15:43
<&ToxicFrog>
If you're on a really old find, it doesn't support '-exec +', only '-exec ;', in which case xargs is the clearly superior choice
15:43
<&ToxicFrog>
Otherwise, -exec + is functionally equivalent to | xargs and may actually use the same code.
15:46
<&McMartin>
I actually didn't know about -exec +~
15:48
< ktemkin[work]>
Googling seems to show that there are advantages to both methods.
15:50
< ktemkin[work]>
While -exec + is typically faster (only one find process to run your commands, instead of find/xargs) and can be chained (you can add additional find options after it), xarg will let you spawn multiple processes with the "-P" flag, so you can run your individual execs in parallel, if the task permits.
15:50
< ktemkin[work]>
*xargs
15:51
< ktemkin[work]>
I suppose you could do that by backgrounding your find calls; but you wouldn't have control over how many processes were running.
15:51
< ktemkin[work]>
"calls" being for lack of a better word. >.>
15:58
<@gnolam>
Azash: cool
16:17 Karono [Karono@Nightstar-13c26ed9.optusnet.com.au] has quit [Client closed the connection]
17:19
< Xires>
I thought awk vs sed was the dumbest argument
17:23
< Syka>
no, that's probably awk vs gawk
17:31
<&ToxicFrog>
PHP vs anything else is the dumbest argument~
17:33
< Syka>
it's also the simplest argument
17:33
< Syka>
"PHP is great!" "No it's not, shut up, before I set you on fire"
17:35
< ErikMesoy>
*before I hit you with this double-clawed hammer
17:35
< Syka>
PHP being a double clawed hammer doesn't make sense to me
17:36
< Syka>
I mean, a hammer has a solid handle
17:36
< Syka>
PHP's handle is like one of those pool noodles
17:37
<@Tamber>
It makes sense in that "You can still actually *use* it to build proper stuff; but it's a lot harder than if you used a decent tool"
18:13
< ktemkin[work]>
And if you assume it works in an at-all standard way, you'll hurt whatever you point it at. ^-^
18:49
<&McMartin>
... huh, SDL has a package update on Fedora.
19:05
<@gnolam>
1.x or 2?
19:10
<&McMartin>
1.x
19:13
<@gnolam>
Strange. I'm not seing anything more recent than 1.2.15 on the SDL web page.
19:14
<&McMartin>
Yeah, this was an update to the 1.2.15 package
19:22
< Syka>
oh my god
19:22
< Syka>
i have spent like... 30 mins to 45 mins on the phone with microsoft
19:22
< Syka>
attempting to get this license activated
19:22
< Syka>
i had to give my name and email (which is fairly complex to spell out) TWICE
19:22
< Syka>
i had to type/speak out the 54 number id FOUR TIMES
19:23
< Syka>
and got transferred THREE TIMES
19:23
< Syka>
the last two people were seemingly unaable to comprehend "019"
19:23
< Syka>
and typed it down as "0891"
19:24
< Syka>
god why is dealing with microsoft licensing such a shitshow
19:26
< Azash>
Syka: http://www.codinghorror.com/.a/6a0120a85dcdae970b017742d249d5970d-800wi
19:29
< Azash>
And speaking of PHP
19:29
< Azash>
http://www.reddit.com/r/netsec/comments/1ju6zh/php_exif_backdoors_generator_usin g_custom/
19:30
< Azash>
"However, preg_replace has a hidden and tricky option where if you pass the /e modifier it will execute the content (eval), instead of just searching/replacing."
19:31
<@gnolam>
"hidden at the top of the php man page for preg_replace"
19:41
<@Namegduf>
XD
19:47
<&ToxicFrog>
Considering what the PHP docs are often like, that may qualify as "hidden"~
20:06 * McMartin crosses a spider with the King of the Koopas.
20:06 * McMartin has crafted a Web Bowser.
20:06
<@TheWatcher>
...
20:30
< Xires>
can someone please load http://www.geany.org/ & tell me what the latest version is? DNS issues are preventing the site from loading on my end
20:31
<@TheWatcher>
1.23.1
20:31
< Xires>
tyvm, TheWatcher
21:40 Kindamoody|afk is now known as Kindamoody
21:45 Kindamoody is now known as Kindamoody[zZz]
22:08 ToxicFrog_ [ToxicFrog@ServerAdministrator.Nightstar.Net] has joined #code
22:09 ToxicFrog [ToxicFrog@4CA975.D980A3.0E5445.043306] has quit [Operation timed out]
22:41 ErikMesoy is now known as ErikMesoy|sleep
22:51 VirusJTG [VirusJTG@Nightstar-09c31e7a.sta.comporium.net] has joined #code
--- Log closed Thu Aug 08 00:00:03 2013
code logs -> 2013 -> Wed, 07 Aug 2013< code.20130806.log - code.20130808.log >

[ Latest log file ]