Trying to understand what's going on here... (Drupal 6.x, MySQL Error, and Debugging)

I’m trying to use a Drupal 6.x website with the Sheetnode 6.x-1.8+8-dev module (it provides a way to create spreadsheets). The module is pretty cool and somewhat hairy to install, but I think it has some bugs (which isn’t unexpected)… I’m currently trying to use this module to export a spreadsheet I created from a Sheetnode-imported XLSX file (which I was only able to do after adjusting my.ini values revolving around execution time and max post size values). Each time I try to export it using the Sheetnode export feature, I get the following (nasty) error:

[INDENT]An error occurred. /projects/foobar/?q=batch&id=31&op=do { “status”: true, “percentage”: 100, “message”: “Exported 1 out of 1 sheets.\x3cbr/\x3eProcessed sheet \x3cem\x3eSheet1\x3c/em\x3e.” }
Warning: include_once(./includes/unicode.entities.inc) [function.include-once]: failed to open stream: No such file or directory in C:\www\projects\foobar\includes\unicode.inc on line 339

Warning: include_once() [function.include]: Failed opening ‘./includes/unicode.entities.inc’ for inclusion (include_path=‘.;C:\php\pear’) in C:\www\projects\foobar\includes\unicode.inc on line 339

Warning: MySQL server has gone away query: INSERT INTO watchdog (uid, type, message, variables, severity, link, location, referer, hostname, timestamp) VALUES (1, ‘php’, ‘%message in %file on line %line.’, ‘a:4:{s:6:\“%error\”;s:7:\“warning\”;s:8:\“%message\”;s:102:\“mysqli_query() [<a href=\‘function.mysqli-query\’>function.mysqli-query</a>]: MySQL server has gone away\”;s:5:\“%file\”;s:53:\“C:\\www\\projects\\foobar\\includes\\database.mysqli.inc\”;s:5:\“%line\”;i:114;}’, 3, ‘’, ‘http://localhost/projects/foobar/?q=batch&id=31&op=do’, ‘http://localhost/projects/foobar/?q=batch&op=start&id=31’, ‘127.0.0.1’, 1354290343) in C:\www\projects\foobar\includes\database.mysqli.inc on line 134

Warning: include_once(modules/dblog/dblog.admin.inc) [function.include-once]: failed to open stream: No such file or directory in C:\www\projects\foobar\sites\all\modules\ldaphelp\ldaphelp.module on line 367
Warning: include_once() [function.include]: Failed opening ‘modules/dblog/dblog.admin.inc’ for inclusion (include_path=‘.;C:\php\pear’) in C:\www\projects\foobar\sites\all\modules\ldaphelp\ldaphelp.module on line 367
Fatal error: Call to undefined function dblog_overview() in C:\www\projects\foobar\sites\all\modules\ldaphelp\ldaphelp.module on line 375
[/INDENT]

So far, I’ve been unsuccessful in completely understanding what’s going on with this and nobody over in the Drupal community seems to, either. I’ve also submitted a support ticket from the module creator, but not surprisingly, it’s been ignored. I was able to find a thread about something similar here, but I don’t think it completely applies because A.) I’m not using Devel, and B.) I’ve tried some of the suggested “fixes” in that thread. Nothing seems to fix it for me.

From everything I’ve read, people claim that this is fixed by increasing various my.ini values (i.e. - max_<whatever>, etc.) I’ve done this–I’ve even gone as far as increasing certain values upward to about 2048 M! Still no dice. I’ve even gone as far as set up a completely brand new Drupal 6.x sandbox with no other modules running–just those that this module needs. Everything works except the exporting feature, which is a deal breaker. (I’ll attach the test spreadsheet I’m trying to test with–it’s in the ZIP file and is very generic / basic.)

Here are the my.ini and php.ini values I’m running with:

In my.ini, I have the following:

  • key_buffer = 384M
  • max_allowed_packet = 1024M
  • table_cache = 4096
  • sort_buffer_size = 512K
  • net_buffer_length = 512K
  • read_buffer_size = 512K
  • read_rnd_buffer_size = 512K
  • myisam_sort_buffer_size = 64M
  • basedir=C:/Program Files (x86)/wamp/bin/mysql/mysql5.5.16
  • log-error=C:/Program Files (x86)/wamp/logs/mysql.log
  • datadir=C:/Program Files (x86)/wamp/bin/mysql/mysql5.5.16/data

Every “myisamchk” parm is set for 512M (for whatever it’s worth).

In php.ini, I have the following:

  • max_execution_time = 120
  • max_input_time = 120
  • memory_limit = 1024M
  • post_max_size = 1024M
  • mysql.cache_size = 2000
  • mysql.connect_timeout = 120

As you can see, there shouldn’t be a problem with memory!

Here’s a list of the associated modules / libraries and where they reside:

  1. /sites/all/modules/sheetnode (version 6.x-1.8+8-dev)
  2. /sites/all/modules/sheetnode/socialcalc (latest version from Git)
  3. /sites/all/libraries/tcpdf (version 5.9.101)
  4. /sites/all/libraries/PHPExcel (version 1.7.8)

The problem is straightforward: I can’t export a spreadsheet to XLS or XLSX format using the Sheetnode export facilities. The process starts, but then bombs-out with that I provided above.

To me (and judging from everything I’ve read so far), it seems like the parsing process responsible for escaping special kinds of encoded characters might be inadvertently allowing some characters to slip through the validation checks, and in turn, causing a cascading issue of interpreting code in certain ways, which is causing all sorts of havoc with things (i.e. - screwing up values of things like inclusion paths as depicted by the fact that the unicode file above it claims it can’t find IS in fact where it should be–which makes no sense). In other words, it seems as if some characters that should be encoded a certain way are slipping through and essentially causing injection issues. But of course, I could be wrong.

I’ve looked at my PHP log and it just has what I posted above. So it’s not much help.

I just hope someone (ANYONE) has some useful feedback about this. How can I try to debug something like this? What methods or functions could / should I use and how / where? Should I just cut my losses and look for another solution? The ticket queue I’ve submitted a ticket to about this is basically useless and who am I to expect help for open-source stuff, right? After all, open-source = generosity, so I guess I should just be happy with what I have…

At any rate, if I’m unclear about anything or if I haven’t provided enough information, please let me know and I’ll try to clarify where necessary. I’d really love to be able to use this thing, but it’s becoming a time sink with little-to-no traction being made.

Wow, that looks messy… I tried Sheetnode a couple of years ago but I don’t recall how far I got with it.

So a couple of things caught my eye. Have you made sure that the files exist and have the correct permissions for:
C:\www\projects\foobar\includes\unicode.inc
C:\www\projects\foobar\sites\all\modules\ldaphelp\ldaphelp.module
C:\www\projects\foobar\includes\database.mysqli.inc

More than likely they do exist but I wonder if the permissions are working correctly.

Also, have you tried running this on a linux/unix sandbox? I used to do a lot of Windows PHP development which I would then move to Unix/Linux for production and there was always trouble with permissions and more with the PHP works between Windows/Linux.

I’ve already given up on it, Andrew. The amount of hassle it kept causing versus the product it provided wasn’t proportionally worth it.

But to answer your questions… I just never thought it was worth putting on one of our Linux machines if it couldn’t work well in the sandbox I had. Heck, if it can’t run right in a fresh install of Drupal with no other modules… And yes, those files exist. What I think was happening here has something to do with characters slipping passed some validation point and causing havoc with interpreted values. I have no clue where, though. I thought it had something do with that unicode stuff, but despite this, I think the REAL issue is occurring well before that include file gets called… So I don’t know. I submitted a help request ticket over on the module homepage, but that was a black-hole and the last straw for me.

Now, however, I’m trying to use the “Slickgrid” view to output a content type that creates pages using the CCK multi-value sub-module. So far, it’s looking good… ;.)

(Knock on wood, right?)

Yeah, it could have been the unicode thing… I hadn’t thought of that. My bet is that it’s a Windows/Unix thing though; there are too many differences in how the two OS’s handle Apache, PHP and permissions.

I still have a Windows sandbox inhouse but I move everything out to a shared account at Site5 or my VPS for any sort of testing. My inhouse sandbox is really just for theming and layout things. I used to have a linux box inhouse as well for dev and I may just resurrect that in the new year so that I can duplicate my VPS inhouse.

I’ll keep my fingers crossed with regard to slickgrid and I think I’ll have to give it a spin myself.

Good luck!

Andrew