lib_mysqludf_preg_info() returns hash instead of version number

[prosperentbrian]

We're running percona's build of mysql 5.5.36-34 on centos 6.5. We have tried installing every release version of lib_mysqludf_preg, and in each case it isn't working properly. When I check the version number with lib_mysqludf_preg_info(), I get back a hash: 6c69625f6d7973716c7564665f7072656720312e31
Instead of the expected version number.

SELECT CONVERT( PREG_REPLACE( '/fox/i' , 'dog' , 'The brown fox' ) USING UTF8) as replaced; returns The brown dog which is ok.

Other queries will sometimes return hashes instead of strings, and in our production system, all spaces are stripped from our results (which has never been the case with older versions of mysql).

Is our installation incorrect? Is this a bug?

[prosperentbrian]

On a side note, I don't see any related errors in our mysql error logs, but when a replace is run, our log file fills up with thousands of lines that simply say REPLA

This actually filled up a drive partition and crashed the server the other night. When I checked the log, we had 50GB of REPLA repeated over and over

[prosperentbrian]

SELECT PREG_CAPTURE('/(.*?)(fox)/' , 'the quick brown fox' ,2 ); Should return FOX", but our install returns: 666f78

unless we change the query to: SELECT CONVERT( PREG_CAPTURE('/(.*?)(fox)/' , 'the quick brown fox' ,2 ) USING UTF8)

We've been using this plugin for years, and we have never had to use the CONVERT, or USING UTF-8. Any ideas?

[richwaters]

Thanks for letting me know about this issue.

If you are seeing the "REPL" message in the logs, it seems like you might not have the latest version installed. Are you cloning from the "testing" branch or downloading the "lib_mysqludf_preg-1.2-rc2" source release?

[Mexxim]

I am experiencing exactly the same problem as 1EightT. I've been using this great library for a while now but never seen those hashes before. It appeared while cloning the "testing" branch- ill try out version 1.2 now

[Mexxim]

result: 1.2 rc2 is giving out hashes too. SELECT CONVERT(LIB_MYSQLUDF_PREG_INFO() USING 'utf8') shows "lib_mysqludf_preg 1.2-rc2", without convert 6c69625f6d7973716c7564665f7072656720312e322d726332

[prosperentbrian]

I believe my issue was that I didn't have pcre-devel installed

Brian Lovett
CEO Prosperent.com

• http://www.prosperent.com*

On Thu, Apr 23, 2015 at 11:41 AM, Mexxim [email protected] wrote:

result: 1.2 rc2 is giving out hashes too. SELECT
CONVERT(LIB_MYSQLUDF_PREG_INFO() USING 'utf8') shows "lib_mysqludf_preg
1.2-rc2", without convert 6c69625f6d7973716c7564665f7072656720312e322d726332

—
Reply to this email directly or view it on GitHub
#14 (comment)
.

[Mexxim]

thanks, but that wasn't the case for me.. all pcre packages are installed correctly. Im running mysql 5.6 on debian wheezy, tried reconfiguring and reinstalling the udfs but witout success so far

[richwaters]

I haven't been able to reproduce this. I created a clean Debian wheezy instance on Digital Ocean for both 32-bit and 64-bit, and I installed mysql-5.6 using the information here: http://www.devops.zone/debian-howtos/installing-mysql-5-6-on-debian-wheezy/

I then did the installs of autoconf, automake, libtool, libpcre3-dev, libmysqlclient-dev.

Then I cloned the testing branch from github, installed the library and ran the tests. I also tried the specific statement given by Mexxim, but everything worked fine.

So, I'm not sure what is causing this. Since it occurs with the LIB_MYSQLUDF_PREG_INFO() function too, I don't think it's related to pcre. I would suspect some sort of mismatch between the client library being linked and the server instance.

[Mexxim]

I'm still missing something. I created a fresh 64bit install too and used exactly your sources.

installed autoconf, make, automake, libtool, libpcre3-dev, libmysqlclient-dev.

git clone https://github.com/mysqludf/lib_mysqludf_preg testing
./configure
make
make install
make installdb
make test -> all "ok"

mysql client library version 5.6.24, just like mysql community server (5.6.24). Do I have to set any additional links?

[richwaters]

I don't think there are any other links.

What's not working? Are you still getting the weird results from the info query?

If the 'make test' worked, that usually means things are working right.

[Mexxim]

RESOLUTION: the UDFs are working just fine but i've queried the database through phpmyadmin for testing purposes. Only phpmyadmin is returning those weird hashes- mysql console, pdo and mysqli are returning correct data. phpmyadmin is already set to utf8 everywhere so i really don't know why its doing that, but i simply wont continue using it for testing the udfs.
Thanks for your help and your great work :)