Oh, that could be fun to hack on. Where is the last updated version of crash-me available?
Is there anything, from a licensing standpoint, that would prevent picking it back up and making it part of Drizzle (or a sub-project or whatnot)? Jeremy On Wed, Aug 5, 2009 at 11:07 AM, David Axmark <[email protected]>wrote: > Its easy to lose those things (like no warnings). We had all of that > early on in MySQL but with more pressure and more people it got lost. > > And the key to avoid that in drizzle is to rely heavily on automatic > checking, we had that early on in MySQL but it got lost (like crash-me > and the simple single threaded benchmarks that was done for every > release). > > I especially disliked to see crash-me go away since it was a cool idea > that I think should be resurrected for drizzle. > > BTW: for those that missed it crash-me was a perl script that tested > limits. Like sending a larger and larger query summing number with > parenthesis. Or trying longer and longer table/field names. > > It was *VERY* efficient in finding limits and bugs in database kernels > and drivers. As I remember only oracle handle it ok in the first try. > Every other db we found bugs in with this little script. > > I highly recommend resurrecting it, or possible build a new one on top > of Philip Stoev's random query generator (that Stewart did some drizzle > porting work on) > > /David > > On Fri, 2009-07-31 at 14:16 -0400, Jay Pipes wrote: > > Lest I be accused of merely bashing MySQL engineering, let me explain > > why I was less-than-slightly amused at the below email thread and > > forwarded it to this list... > > > > Early on in the development of Drizzle, Brian, Monty T, Stewart and I > > spent hundreds of hours fixing nasty, hard-to-diagnose bugs just like > > these. Seeing this email brought back some not-so-happy memories of > > that refactoring work. > > > > Why does Drizzle not suffer from these kind of bugs (or at least very > > few of them) compared to MySQL? Very simple: our build/compile process. > > > > Compilers emit warnings for a reason. When you ignore those warnings > > (such as a variable's data could be truncated via a cast), you let your > > code get exposed to these kind of bugs. By enabling -Werror and > > compiling with VERY strict warnings, these kinds of bugs are caught > > EARLY by the compiler, which complains that you are trying to do > > something that may not be a good idea! > > > > Anyway, I apologize for including private email addresses in the > > forward, but the lessons of strict compilation's benefits should not be > > forgotten. > > > > -jay > > > > Jay Pipes wrote: > > > LMAO. > > > > > > -------- Original Message -------- > > > Subject: Re: Exercise of the day: calling my_read() ... > > > Sinisa, > > > > > >> 5.1 uses (correctly) size_t instead of int's ... > > > > > > Nah, I disagree. It does use size_t but I would argue it doesn't do so > > > correctly. > > > > > > Count is size_t: > > > > > >> size_t my_read(File Filedes, uchar *Buffer, size_t Count, myf MyFlags) > > > > > > It is passed as an argument to read(2) where a size_t is expected. > > > > > >> if ((readbytes= read(Filedes, Buffer, (uint) Count)) != Count) > > > > > > Oh wait, we have a size_t and need a size_t but cast it to uint just > for > > > the fun of it? This means that reading Count > UINT_MAX bytes will not > > > work even if size_t is wider than uint (which it may well be on a 32 > bit > > > system). > > > > > > On the same line, the result of read(2) is stored in readbytes, which > is > > > size_t. However, the result type of read(2) is ssize_t on most > > > platforms. Normally size_t is signed too on UNIX so we are in luck. > Also > > > it's likely that ssize_t and size_t would have the same width in any > case. > > > > > > By the way, on the line above the read(2) call I find this: > > > > > >> errno= 0; /* Linux doesn't reset this */ > > > > > > Of course Linux doesn't reset it; no standard-conforming function that > > > uses errno to return an error will reset it... > > > > > > Anyway, later, readbytes is cast to int, in order to compare to -1 > > > (which is an int literal in this case): > > > > > >> if ((readbytes == 0 || (int) readbytes == -1) && errno == EINTR) > > > > > > This means that any read of size S from an interrupted call where S % > > > UINT_MAX == -1 will be interpreted as a failure and the data is lost, > so > > > we can definitely not trust it with Count > UINT_MAX even if we remove > > > the blocking cast. Of course this is unlikely to happen in reality > > > because the syscall has to be interrupted for this to trigger. > > > > > > In some another place it is cast to long for printing. Since that is > > > debug code it doesn't really matter: > > > > > >> DBUG_PRINT("debug", ("my_read() was interrupted and returned %ld", > > >> (long) readbytes)); > > > > > > Although it also appears cast to int in debug messages, so we likely > > > don't know what we want anyway: > > > > > >> DBUG_PRINT("warning",("Read only %d bytes off %lu from %d, errno: %d", > > >> (int) readbytes, (ulong) Count, Filedes, > > >> my_errno)); > > > > > > In the same debug statement, Count is also cast to ulong for printing > > > even though we cast it to uint for execution and only expect to read a > > > block of size <= INT_MAX as evidenced by the cast of readbytes to int > in > > > the same message. This doesn't actually break reading > INT_MAX but it > > > is clear that we don't expect to do read blocks that large. (There is a > > > typo there in the English text too.) > > > > > > Elsewhere, it is not cast to int, but instead compared to (size_t) -1: > > > > > >> if (readbytes == (size_t) -1) > > > > > > This usually works, but if size_t is wider than int, a size_t value of > > > -1 will not be equal to an int value of -1 cast to size_t, and because > > > of that the equality test will have a different result. > > > > > > ++ > > > > > > I would not trust this function with anything > INT_MAX, and I'm not > > > even sure I would trust it with anything > 50 or so. > > > > > > > > > Daniel > > > > > > > > > _______________________________________________ > > Mailing list: > > https://launchpad.net/~drizzle-discuss<https://launchpad.net/%7Edrizzle-discuss> > > Post to : [email protected] > > Unsubscribe : > > https://launchpad.net/~drizzle-discuss<https://launchpad.net/%7Edrizzle-discuss> > > More help : https://help.launchpad.net/ListHelp > > > _______________________________________________ > Mailing list: > https://launchpad.net/~drizzle-discuss<https://launchpad.net/%7Edrizzle-discuss> > Post to : [email protected] > Unsubscribe : > https://launchpad.net/~drizzle-discuss<https://launchpad.net/%7Edrizzle-discuss> > More help : https://help.launchpad.net/ListHelp >
_______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
