Re: [Virtuoso-users] Long read issues with PHP odbc
Hi, I came across this mail from Fred Giasson in the SF list archive [1]: Hi Everybody, I am facing long read issue with one of my server (when sparqling). The server runs: (1) Virtuoso 5.12.3041 (2) PHP 5.3.2 (3) It uses the default unixodbc drivers that comes with ubuntu (4) I am using DB.DBA.SPARQL_EVAL to wrap the sparql queries via the PHP-ODBC API. So, basically, the problem is that long values get truncated at 4070 bytes (which is Virtuoso's max, after this it is supposed to get into a blob, but apparently that it has some issues reading it), and then garbage is added after these 4070 (some kind of stack overflow) bytes. I tested: (1) I tested a full set of parameters in odbc_connect (the flag). To increase the defaultlrl php.ini setting, to play with the binmode, to use the odbc_longreadlen() api call, etc. Nothing works. (2) I confirm that I don't have this issue when using iSql/Conductor (probably since it uses vsp iodbc) I want to know: (1) if there is some ways to fix this using some PHP API (2) if this is a bug, and if this has been fixed in 5.14 (3) if this will only works with iodbc drivers Thanks! Take care, Fred I'm stuck with the same problem using Virtuoso 6.1.5 on PHP 5.3 (albeit using SQL directly, not SPARQL). Symptoms are the same, no matter what I have tried, I simply cannot get PHP's ODBC implementation to read LONG NVARCHAR columns with Virtuoso ODBC driver. I also get some junk at the end of the data same as Fred describes. I'm using PHP with unixODBC (because iODBC is apparently going away in Debian) but I don't see that it ought to make any difference. If it would, I can consider changing to iODBC, but that would be quite disruptive to my work so I'd rather not try it just on the off-chance. If anybody at OpenLink (or elsewhere) has any suspicions about where exactly the problem here lies (PHP, unixODBC, Virtuoso, some connection parameter...) I can do my part to try to patch etc. but I could really use some pointers for where to start looking. Cheers! -Will [1] https://sourceforge.net/mailarchive/message.php?msg_id=27447958
Re: [Virtuoso-users] Long read issues with PHP odbc
On 4/16/12 1:38 PM, Will Daniels wrote: OK forget this, it's definitely a PHP problem. Sorry for the noise. -Will Yes, but we get the blame for everything :-) Now I have to ponder about what's making Debian feel it makes sense to move away from iODBC . Kingsley On 16/04/12 12:37, Will Daniels wrote: Hi, I came across this mail from Fred Giasson in the SF list archive [1]: Hi Everybody, I am facing long read issue with one of my server (when sparqling). The server runs: (1) Virtuoso 5.12.3041 (2) PHP 5.3.2 (3) It uses the default unixodbc drivers that comes with ubuntu (4) I am using DB.DBA.SPARQL_EVAL to wrap the sparql queries via the PHP-ODBC API. So, basically, the problem is that long values get truncated at 4070 bytes (which is Virtuoso's max, after this it is supposed to get into a blob, but apparently that it has some issues reading it), and then garbage is added after these 4070 (some kind of stack overflow) bytes. I tested: (1) I tested a full set of parameters in odbc_connect (the flag). To increase the defaultlrl php.ini setting, to play with the binmode, to use the odbc_longreadlen() api call, etc. Nothing works. (2) I confirm that I don't have this issue when using iSql/Conductor (probably since it uses vsp iodbc) I want to know: (1) if there is some ways to fix this using some PHP API (2) if this is a bug, and if this has been fixed in 5.14 (3) if this will only works with iodbc drivers Thanks! Take care, Fred I'm stuck with the same problem using Virtuoso 6.1.5 on PHP 5.3 (albeit using SQL directly, not SPARQL). Symptoms are the same, no matter what I have tried, I simply cannot get PHP's ODBC implementation to read LONG NVARCHAR columns with Virtuoso ODBC driver. I also get some junk at the end of the data same as Fred describes. I'm using PHP with unixODBC (because iODBC is apparently going away in Debian) but I don't see that it ought to make any difference. If it would, I can consider changing to iODBC, but that would be quite disruptive to my work so I'd rather not try it just on the off-chance. If anybody at OpenLink (or elsewhere) has any suspicions about where exactly the problem here lies (PHP, unixODBC, Virtuoso, some connection parameter...) I can do my part to try to patch etc. but I could really use some pointers for where to start looking. Cheers! -Will [1] https://sourceforge.net/mailarchive/message.php?msg_id=27447958 -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Virtuoso-users mailing list Virtuoso-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtuoso-users !DSPAM:4f8c0487161845508517005! -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Virtuoso-users mailing list Virtuoso-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtuoso-users -- Regards, Kingsley Idehen Founder CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca handle: @kidehen Google+ Profile: https://plus.google.com/112399767740508618350/about LinkedIn Profile: http://www.linkedin.com/in/kidehen smime.p7s Description: S/MIME Cryptographic Signature
Re: [Virtuoso-users] Long read issues with PHP odbc
HI Will, OK forget this, it's definitely a PHP problem. Sorry for the noise. If you can tell me what is going wrong with PHP, i still maybe able to help by sending them a bugfix if need be. Patrick --- Maintainer iODBC
Re: [Virtuoso-users] Long read issues with PHP odbc
Hi Patrick,
On 16/04/12 20:15, Patrick van Kleef wrote:
If you can tell me what is going wrong with PHP, i still maybe able to help by
sending them a bugfix if need be.
I think it has to do with allocation of the default read buffer in PHP ODBC
module somehow. After checking that it worked fine in perl using unixODBC I
retested all the ways to control this behaviour in PHP and eventually I found
that increasing the default buffer size solves the issue, e.g.
ini_set('odbc.defaultlrl', '100');
I thought I had tried that setting directly in the php.ini before without
success, but perhaps I changed it for the non-ZTS build by mistake. Setting it
in code is certainly working for me right now.
But setting anything (zero or a large value) via odbc_longreadlen doesn't work
as it should. It seems like the buffer gets increased in size, but then the
overflow after 4000-something bytes is full of random junk from the
stack/heap. Sometimes including PHP script fragments (so it's sort of a security
issue).
Not sure yet why people using other ODBC drivers have not reported the issue
(AFAICT) but I haven't investigated very far. I noticed something in the PHP bug
tracker[1] against v5.2.13 that talks about meddling in this general area, but
it's not clear whether that patch was applied or not, and I've yet to check the
enormous list of patches that Debian applies to it's PHP packages (which is
essentially what I'm using, I just modified the package to build a ZTS
variant[2] for Virtuoso).
I haven't tested newer PHP builds either.
It will take quite some time to sort this out with PHP myself, so your
assistance would be very much appreciated.
Cheers!
-Will
[1] https://bugs.php.net/bug.php?id=51606
[2] https://launchpad.net/~wdaniels/+archive/virtuoso-php
Re: [Virtuoso-users] Long read issues with PHP odbc
On 16/04/12 18:42, Kingsley Idehen wrote: Now I have to ponder about what's making Debian feel it makes sense to move away from iODBC . I read it in a Launchpad bug[1], comment from Steve Langasek (vorlon): The oneiric tdsodbc Recommends: libiodbc2 | unixodbc, so libiodbc2 gets pulled in automatically as the first solution. The precise tdsodbc Breaks: libiodbc2 because precise is moving to multiarch paths for ODBC drivers, and libiodbc2 doesn't implement this (and won't, the package is orphaned and will be removed from Debian unstable and precise just as soon as I get a solution for soprano to work with unixodbc). So I guess you just need to get someone to maintain that package. I would offer but I'm not a Debian (or Ubuntu) Developer so I don't think I can help much there. -Will [1] https://bugs.launchpad.net/ubuntu/+source/unixodbc/+bug/901638
