Greetings,
I'm busy revamping the BUG() code in the SQL Parser, including making things more PHP3 compatible, and putting the strings into the lang/* files instead of inside the main sqlparser, so they they can be translated.
There is one major functionality change. The existing -rc4 and CVS code did a die() call on a failure of the parser, I did that for the moment to strongly encourage bug reports. I've got them fixed now, so the behaviour is changing just to printing out the error message from the parser system, and carrying on doing whatever else was being done.
At the moment, the BUG() code has been abstracted to PMA_SQP_BUG() in the SQLParser library, but in 2.3.1 or otherwise soonish, PMA will gain a proper BUG() function.
My PMA_SQP_BUG() presently includes: Error Message CVS $Id$ of sqlparser MySQL version User OS/Browser/BrowserVersion PMA version PMA version/OS SQL query
Do you have any other suggestions of things that might be handy to have in tracking down bugs?
There is also PMA_SQP_throwError() for when you want to inform the user of a possible error on their part, that is not an error with our code.
----- Original Message ----- From: "Robin Johnson" robbat2@fermi.orbis-terrarum.net
There is one major functionality change. The existing -rc4 and CVS code did a die() call on a failure of the parser, I did that for the moment to strongly encourage bug reports. I've got them fixed now, so the behaviour is changing just to printing out the error message from the parser system, and carrying on doing whatever else was being done.
Perhaps this should be handled by a config variable like $cfg['UseDebugMode'] = { TRUE | FALSE }; I blieve that there are some users out there that install phpMyAdmin on a non-productional machine and want to support our development. Of course, this directive should default to FALSE in final versions.
At the moment, the BUG() code has been abstracted to PMA_SQP_BUG() in the SQLParser library, but in 2.3.1 or otherwise soonish, PMA will gain a proper BUG() function.
My PMA_SQP_BUG() presently includes: Error Message CVS $Id$ of sqlparser MySQL version User OS/Browser/BrowserVersion PMA version PMA version/OS SQL query
Do you have any other suggestions of things that might be handy to have in tracking down bugs?
HTTP server software / version, php version, MySQL version... Perhaps some information about the php / MySQL configuration... Windows XP activation key, root password, the user's shoe size...
Happy Coding,
Alexander
Perhaps this should be handled by a config variable like $cfg['UseDebugMode'] = { TRUE | FALSE }; I blieve that there are some users out there that install phpMyAdmin on a non-productional machine and want to support our development. Of course, this directive should default to FALSE in final versions.
Of the two error functions, there is PMA_SQP_throwError() and PMA_SQP_BUG() [modelled after the linux kernel BUG()].
throwError is a case where the user has given us bad input that we know what is wrong with the query (Invalid Number String, Invalid Punctation String, Unmatched Quotes). These are the errors that MySQL will fail on as well, and the MySQL error return isn't terribly helpful sometimes, so my error messages can help a lot.
BUG is a much rarer case, presently the only time it occurs is when the parser hits a character that MySQL would totally fail on. So far the only occurances of this ever happening in the bug tracker have been when people have uploaded files with unquoted binary content to PMA. I am not certain if I should convert this into a call to check for such binary content and warn people or not. Maybe as a special case before the BUG() call ?
My PMA_SQP_BUG() presently includes:
Error Message CVS $Id$ of sqlparser MySQL version User OS/Browser/BrowserVersion PMA version PMA version/OS SQL query
Do you have any other suggestions of things that might be handy to have in tracking down bugs?
HTTP server software / version,
What are the best variable names to use to get these?
php version, MySQL version...
Got those.
Perhaps some information about the php / MySQL configuration...
Could you be more specific? I've considered included the page that the BUG() call was made from, but that isn't really needed yet.
Windows XP activation key, root password, the user's shoe size...
lol, those will never happen.
Hi
Windows XP activation key, root password, the user's shoe size...
lol, those will never happen.
Great ;-)
Shouldn't there be also mentioned what is contained in those "garbage" that should be used in bugreport? And possibly way how user can verify this... When somebody will find bug when inserting some private data he should at least know that sql is included in that bugreport.
Michal Cihar
----- Original Message ----- From: "Michal Cihar" cihar@liten.cz
Shouldn't there be also mentioned what is contained in those "garbage" that should be used in bugreport? And possibly way how user can verify this... When somebody will find bug when inserting some private data he should at least know that sql is included in that bugreport.
Have you ever wondered what scripts/decode_bug.php3 does? ;-)
Alexander
On Fri, 9 Aug 2002, Rabus wrote:
From: "Michal Cihar" cihar@liten.cz
Shouldn't there be also mentioned what is contained in those "garbage" that should be used in bugreport? And possibly way how user can verify this... When somebody will find bug when inserting some private data he should at least know that sql is included in that bugreport.
Have you ever wondered what scripts/decode_bug.php3 does? ;-)
He does have a point that this isn't documented anywhere other than on the mailing list. I'll put in an FAQ item about it.
-
Michal Cihar -
Rabus -
Robin Johnson