When an error report happens now I collect certain relevant info about the error and current phpmyadmin configuration.
I currently collect error message, line number, file_name, stacktrace if available, phpmyadmin version, user browser name and version, user os and steps for reproduction by the user.
do you think any other thing is relevant to the report. I can easily add any more info if required I just cant seem to find what is important for debugging. I thought I would ask you since you have a lot of experience debugging problems in phpmyadmin
On 06/19/2013 08:17 PM, Mohamed Ashraf wrote:
When an error report happens now I collect certain relevant info about the error and current phpmyadmin configuration.
I currently collect error message, line number, file_name, stacktrace if available, phpmyadmin version, user browser name and version, user os and steps for reproduction by the user.
do you think any other thing is relevant to the report. I can easily add any more info if required I just cant seem to find what is important for debugging. I thought I would ask you since you have a lot of experience debugging problems in phpmyadmin
There should be some more ideas of what to report here: http://wiki.phpmyadmin.net/pma/GSoC_2013_AJAX_error_reporting
Bye, Rouslan
On Wed, Jun 19, 2013 at 9:20 PM, Rouslan Placella rouslan@placella.com wrote:
On 06/19/2013 08:17 PM, Mohamed Ashraf wrote:
When an error report happens now I collect certain relevant info about the error and current phpmyadmin configuration.
I currently collect error message, line number, file_name, stacktrace if available, phpmyadmin version, user browser name and version, user os and steps for reproduction by the user.
do you think any other thing is relevant to the report. I can easily add any more info if required I just cant seem to find what is important for debugging. I thought I would ask you since you have a lot of experience debugging problems in phpmyadmin
There should be some more ideas of what to report here: http://wiki.phpmyadmin.net/pma/GSoC_2013_AJAX_error_reporting
Bye, Rouslan
One of the entries on that page refers to microhistory entries. in AJAX.cache.pages where the history is cached every entry has a hash which is something like "server_sql.php?db=&table=&server=1&target=&token=a93160163bf70c1f5f9c4426adcb3a36" and the content of the page, params, list of scripts and self link. I think it is of no use to send the content of the cached pages in the error report and same for the self link and list of scripts. so I think the most obvious things for inclusion in the report is the hash and the params. Am I correct or am I missing something?
however I don't understand why is the list of cached pages important anyways. Can someone tell me how it may help us diagnose an bug so I can know what pieces of info I should focus on including or is this just there in case it contains any info that may be of use and you are not looking for something in particular.
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Phpmyadmin-devel mailing list Phpmyadmin-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
On 06/20/2013 08:22 AM, Mohamed Ashraf wrote:
On Wed, Jun 19, 2013 at 9:20 PM, Rouslan Placella rouslan@placella.com wrote:
On 06/19/2013 08:17 PM, Mohamed Ashraf wrote:
When an error report happens now I collect certain relevant info about the error and current phpmyadmin configuration.
I currently collect error message, line number, file_name, stacktrace if available, phpmyadmin version, user browser name and version, user os and steps for reproduction by the user.
do you think any other thing is relevant to the report. I can easily add any more info if required I just cant seem to find what is important for debugging. I thought I would ask you since you have a lot of experience debugging problems in phpmyadmin
There should be some more ideas of what to report here: http://wiki.phpmyadmin.net/pma/GSoC_2013_AJAX_error_reporting
Bye, Rouslan
One of the entries on that page refers to microhistory entries. in AJAX.cache.pages where the history is cached every entry has a hash which is something like "server_sql.php?db=&table=&server=1&target=&token=a93160163bf70c1f5f9c4426adcb3a36" and the content of the page, params, list of scripts and self link. I think it is of no use to send the content of the cached pages in the error report and same for the self link and list of scripts. so I think the most obvious things for inclusion in the report is the hash and the params. Am I correct or am I missing something?
however I don't understand why is the list of cached pages important anyways. Can someone tell me how it may help us diagnose an bug so I can know what pieces of info I should focus on including or is this just there in case it contains any info that may be of use and you are not looking for something in particular.
The array of cached pages is in chronological order and AJAX.cache.current tells you where the user is at the moment. Given this information you can tell which pages the user just came from. If there are entries with a higher index that AJAX.cache.current, it means that the user was travelling backwards in the history, otherwise he was just browsing normally.
The urls of the pages would be sufficient for the report, I guess...
Hope this helps.
Bye, Rouslan
-
Mohamed Ashraf -
Rouslan Placella