Problem with QMPHP Subroutine

George R Smith

unread,

May 8, 2012, 7:13:09 AM5/8/12

to ope...@googlegroups.com

All,

I am testing out QMPHP on a 64 bit Debian box.

All examples are working except for a call to a QM

subroutine.

The subroutine works if the string is less than

14 characters. The example given returns a string

of “blah*blah” which is 9 characters.

Sub is:

SUB.TEST

01: SUBROUTINE SUB.TEST(ARG,X.ARG)

02:

03: $CATALOG SUB.TEST LOCAL

04:

05: * ARG = ARG: "*": ARG

06: ARG = "ABCDEGHIJKLMNOPQ"

07:

08: X.ARG = "E"

09: RETURN

10: END

PHP code is:

root@dellT710:/var/www# cat qm_call.php

<?php

QMConnectLocal("aAccount");

$arg_1 = "ALL";

$arg_2 = "arg_2";

QMCall("SUB.TEST", 2,&$arg_1,&$arg_2);

echo $arg_1;

echo "\n";

echo $arg_2;

echo "\n";

QMDisconnectAll();

?>

Calling SUB.TEST when the string to be returned is

ARG = "ABCDEGHIJKLMNOPQ causes what I

have been told is a seqment fault and crashes

to the linux prompt.

root@dellT710:/var/www# php qm_call.php

*** glibc detected *** php: free(): invalid next size (fast): 0x0a6a3858 ***

Thanks to all.

Anyone have any suggestions.

George

full error message

===============================

root@dellT710:/var/www# php qm_call.php

*** glibc detected *** php: free(): invalid next size (fast): 0x0a6a3858 ***

======= Backtrace: =========

/lib/i686/cmov/libc.so.6(+0x6b381)[0xf70c0381]

/lib/i686/cmov/libc.so.6(+0x6cbd8)[0xf70c1bd8]

/lib/i686/cmov/libc.so.6(cfree+0x6d)[0xf70c4cbd]

/usr/lib/php5/20090626+lfs/qmphp.so(zif_QMCall+0x2be)[0xf6cccdce]

php(execute_internal+0x4b)[0x831eb8b]

/usr/lib/php5/20090626+lfs/suhosin.so(+0x15fa3)[0xf64d4fa3]

php[0x834aa58]

php(execute+0x1ce)[0x832151e]

/usr/lib/php5/20090626+lfs/suhosin.so(+0x16404)[0xf64d5404]

php(zend_execute_scripts+0x66)[0x82f7296]

php(php_execute_script+0x1e4)[0x829b4c4]

php[0x838d84b]

/lib/i686/cmov/libc.so.6(__libc_start_main+0xe6)[0xf706bca6]

php[0x806bbc1]

======= Memory map: ========

08048000-0871f000 r-xp 00000000 08:01 9453192 /usr/bi

n/php5

0871f000-0875e000 r--p 006d7000 08:01 9453192 /usr/bi

n/php5

0875e000-08764000 rw-p 00716000 08:01 9453192 /usr/bi

n/php5

08764000-0877b000 rw-p 00000000 00:00 0

0a558000-0a744000 rw-p 00000000 00:00 0 [heap]

f5b00000-f5b21000 rw-p 00000000 00:00 0

f5b21000-f5c00000 ---p 00000000 00:00 0

f5c94000-f5cb1000 r-xp 00000000 08:01 36003843 /lib/li

bgcc_s.so.1

f5cb1000-f5cb2000 rw-p 0001c000 08:01 36003843 /lib/li

bgcc_s.so.1

f5cb2000-f5cb3000 ---p 00000000 00:00 0

f5cb3000-f64b3000 rwxp 00000000 00:00 0

f64b3000-f64bd000 r-xp 00000000 08:01 36028681 /lib/i6

86/cmov/libnss_files-2.11.3.so

f64bd000-f64be000 r--p 00009000 08:01 36028681 /lib/i6

86/cmov/libnss_files-2.11.3.so

f64be000-f64bf000 rw-p 0000a000 08:01 36028681 /lib/i6

86/cmov/libnss_files-2.11.3.so

f64bf000-f64df000 r-xp 00000000 08:01 9504820 /usr/li

b/php5/20090626+lfs/suhosin.so

f64df000-f64e3000 rw-p 0001f000 08:01 9504820 /usr/li

b/php5/20090626+lfs/suhosin.so

f64e3000-f64e5000 rw-p 00000000 00:00 0

f64e5000-f64eb000 r-xp 00000000 08:01 9504862 /usr/li

b/php5/20090626+lfs/pdo_mysql.so

f64eb000-f64ec000 r--p 00005000 08:01 9504862 /usr/li

b/php5/20090626+lfs/pdo_mysql.so

f64ec000-f64ed000 rw-p 00006000 08:01 9504862 /usr/li

b/php5/20090626+lfs/pdo_mysql.so

f64ed000-f6500000 r-xp 00000000 08:01 9503395 /usr/li

b/php5/20090626+lfs/pdo.so

f6500000-f6502000 r--p 00013000 08:01 9503395 /usr/li

b/php5/20090626+lfs/pdo.so

f6502000-f6503000 rw-p 00015000 08:01 9503395 /usr/li

b/php5/20090626+lfs/pdo.so

f6503000-f651b000 r-xp 00000000 08:01 9504863 /usr/li

b/php5/20090626+lfs/mysqli.so

f651b000-f651e000 r--p 00017000 08:01 9504863 /usr/li

b/php5/20090626+lfs/mysqli.so

f651e000-f651f000 rw-p 0001a000 08:01 9504863 /usr/li

b/php5/20090626+lfs/mysqli.so

f651f000-f66d2000 r-xp 00000000 08:01 12943509 /usr/li

b/libmysqlclient_r.so.16.0.0

f66d2000-f66d6000 r--p 001b2000 08:01 12943509 /usr/li

b/libmysqlclient_r.so.16.0.0

f66d6000-f671b000 rw-p 001b6000 08:01 12943509 /usr/li

b/libmysqlclient_r.so.16.0.0

f671b000-f671c000 rw-p 00000000 00:00 0

f671c000-f6725000 r-xp 00000000 08:01 9504864 /usr/li

b/php5/20090626+lfs/mysql.so

f6725000-f6727000 r--p 00008000 08:01 9504864 /usr/li

b/php5/20090626+lfs/mysql.so

f6727000-f6728000 rw-p 0000a000 08:01 9504864 /usr/li

b/php5/20090626+lfs/mysql.so

f6728000-f672f000 r-xp 00000000 08:01 12943513 /usr/li

b/libltdl.so.7.2.1

f672f000-f6730000 rw-p 00007000 08:01 12943513 /usr/li

b/libltdl.so.7.2.1

f6730000-f6755000 r-xp 00000000 08:01 12943526 /usr/li

b/libmcrypt.so.4.4.8

f6755000-f6758000 rw-p 00025000 08:01 12943526 /usr/li

b/libmcrypt.so.4.4.8

f6758000-f675d000 rw-p 00000000 00:00 0

f675d000-f6765000 r-xp 00000000 08:01 9504871 /usr/li

b/php5/20090626+lfs/mcrypt.so

f6765000-f6767000 r--p 00007000 08:01 9504871 /usr/li

b/php5/20090626+lfs/mcrypt.so

f6767000-f6768000 rw-p 00009000 08:01 9504871 /usr/li

b/php5/20090626+lfs/mcrypt.so

f6768000-f676c000 r-xp 00000000 08:01 9451699 /usr/li

b/libXdmcp.so.6.0.0

f676c000-f676d000 rw-p 00003000 08:01 9451699 /usr/li

b/libXdmcp.so.6.0.0

f676d000-f676f000 r-xp 00000000 08:01 9451697 /usr/li

b/libXau.so.6.0.0

f676f000-f6770000 rw-p 00001000 08:01 9451697 /usr/li

b/libXau.so.6.0.0

f6770000-f6794000 r-xp 00000000 08:01 9446554 /usr/li

b/libexpat.so.1.5.2

f6794000-f6796000 rw-p 00023000 08:01 9446554 /usr/li

b/libexpat.so.1.5.2

f6796000-f67ae000 r-xp 00000000 08:01 9451701 /usr/li

b/libxcb.so.1.1.0

f67ae000-f67af000 rw-p 00017000 08:01 9451701 /usr/li

b/libxcb.so.1.1.0

f67af000-f67dc000 r-xp 00000000 08:01 12943437 /usr/li

b/libfontconfig.so.1.4.4

f67dc000-f67de000 rw-p 0002c000 08:01 12943437 /usr/li

b/libfontconfig.so.1.4.4

f67de000-f67fd000 r-xp 00000000 08:01 9450805 /usr/li

b/libjpeg.so.62.0.0

f67fd000-f67fe000 rw-p 0001e000 08:01 9450805 /usr/li

b/libjpeg.so.62.0.0

f67fe000-f6821000 r-xp 00000000 08:01 36004292 /lib/li

bpng12.so.0.44.0

f6821000-f6822000 rw-p 00022000 08:01 36004292 /lib/li

bpng12.so.0.44.0

f6822000-f6831000 r-xp 00000000 08:01 12943524 /usr/li

b/libXpm.so.4.11.0

f6831000-f6832000 rw-p 0000e000 08:01 12943524 /usr/li

b/libXpm.so.4.11.0

f6832000-f694b000 r-xp 00000000 08:01 9451705 /usr/li

b/libX11.so.6.3.0

f694b000-f694f000 rw-p 00118000 08:01 9451705 /usr/li

b/libX11.so.6.3.0

f694f000-f69c3000 r-xp 00000000 08:01 9450803 /usr/li

b/libfreetype.so.6.6.0Aborted

root@dellT710:/var/www#

Martin Phillips

unread,

May 8, 2012, 7:46:09 AM5/8/12

to ope...@googlegroups.com

Hi George,

QMPHP is a third party contribution maintained by Montgomery Tidwell. I have alerted him to this mailing thread.

Martin Phillips
Ladybridge Systems Ltd
17b Coldstream Lane, Hardingstone, Northampton NN4 6DB, England
+44 (0)1604-709200

--
You received this message because you are subscribed to the Google Groups "OpenQM" group.
To post to this group, send an email to ope...@googlegroups.com.
To unsubscribe from this group, send email to openqm+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/openqm?hl=en-GB.

Kevin Powick

unread,

May 8, 2012, 9:02:52 AM5/8/12

to ope...@googlegroups.com

It would be best if the original author replied, but my guess would be a memory error.

WIth the version of QMCall that uses the QMClient C library, one must allocate a buffer of a large enough size for each return value of the subroutine. I don't know how QMPHP is doing this, but it does not appear that the syntax allows for the user to provide a buffer size parameter. So, perhaps the function is arbitrarily allocating the space. I cannot really see how that would work though, as who knows how much data a user might decide to return from their called subroutine.

One solution is to have your subroutine write results to a work file with a unique ID, and return that ID to the calling program. The calling program would then do a QMRead of that file, using the ID. This avoids memory allocation issues, as QMRead handles it automatically. The performance hit of an extra write/read is negligible to the point of not mattering at all, IMO.

--

Kevin Powick

George R Smith

unread,

May 8, 2012, 9:09:35 AM5/8/12

to ope...@googlegroups.com

Kevin,

Right, same principle you use with your Delphi wrapper. I was going to look at that as an

alternative.

I am looking at this because of Tim Young’s Webbuilder. I still like the Delphi windows forms programs

but you know this web/browser thing.

Thanks Kevin,

george

--

You received this message because you are subscribed to the Google Groups "OpenQM" group.

To view this discussion on the web, visit https://groups.google.com/d/msg/openqm/-/SWH3zDQ5hq0J.

Martin Phillips

unread,

May 8, 2012, 9:24:36 AM5/8/12

to ope...@googlegroups.com

Hi all,

Although QMPHP is not ours, I do recall an issue with allocation of memory for subroutine return arguments. I thought that this had been fixed. Perhaps not.

Since release 2.12-1 (may 2011), QMClient includes a QMCallx() function that calls a subroutine just like QMCall() but retains the argument values internally from where they can subsequently be retrieved using QMGetArg() which will handle memory allocation. Probably the PHP API should use this method.

Kevin Powick

unread,

May 8, 2012, 11:11:27 AM5/8/12

to ope...@googlegroups.com

Hi George,

On Tuesday, 8 May 2012 09:09:35 UTC-4, grs wrote:

I am looking at this because of Tim Young’s Webbuilder. I still like the Delphi windows forms programsbut you know this web/browser thing.

I was looking at the beta, but found it a bit buggy, though I haven't looked for newer versions in the past few months.

I'm wondering if the Smart Mobile Studio project will gain more traction. It seems pretty comprehensive and has more than just one person working on it.

http://op4js.optimalesystemer.no/

--

Kevin Powick

Mike

unread,

May 9, 2012, 4:12:08 AM5/9/12

to ope...@googlegroups.com

Kevin,

Thanks for that link - looks interesting.
What we require now is the similar thing in QM so that you can write a program in basic and it gets converted to javascript. Wou;dn't that be wonderful.

Mike

Kevin Powick

unread,

May 9, 2012, 9:14:52 AM5/9/12

to ope...@googlegroups.com

Hi Mike

On Wednesday, 9 May 2012 04:12:08 UTC-4, Mike wrote:

What we require now is the similar thing in QM so that you can write a program in basic and it gets converted to javascript. Wou;dn't that be wonderful.

The power of QMBasic, or any of the MV BASICs, is the ability to manipulate the database on the server. Since JavaScript is predominantly a client-side technology that runs in a web browser, and such a small subset of MV BASIC would be of any use as JavaScript, I can't really see any great advantage to a product that would convert MV BASIC code to JavaScript.

--

Kevin Powick

George R Smith

unread,

May 9, 2012, 9:39:09 AM5/9/12

to ope...@googlegroups.com

I feel that what we need as application developers is the QMPHP supported and sold by Ladybridge.

It is good and we should be appreciative of those outsiders that develop the QMPHP and the Delphi wrappers

but it should be a product of the database vendors and supported by the database vendors in my opinion, otherwise it is just not tenable.

Those who know me know that I do not have any problem paying for product but it has to be provided and supported by Ladybridge, Northgate, Rocket etc.

Just my opinion.

George

Kevin Powick

unread,

May 9, 2012, 10:24:35 AM5/9/12

to ope...@googlegroups.com

On Wednesday, 9 May 2012 09:39:09 UTC-4, grs wrote:

It is good and we should be appreciative of those outsiders that develop the QMPHP and the Delphi wrappersbut it should be a product of the database vendors and supported by the database vendors in my opinion, otherwise it is just not tenable.

Then where does it end? With how many connectivity options should Ladybridge have expertise? They've provided the QM Client library for all platforms, giving us pretty much everything one needs to connect to anything, and it's fully supported by Ladybridge.

Several people, such as myself, have written and shared various "helper" libraries to make integration of QM Client a little more "native" to a particular development language, but it wasn't necessary. Anyone with proficiency in their development language of choice should be able to work with the QM Client library, directly.

Maybe it would be nice if QM came with some additional connectivity "out of the box", but I would rather that Ladybridge remain focused on QM's performance and stability.

--

Kevin Powick

George R Smith

unread,

May 9, 2012, 10:38:58 AM5/9/12

to ope...@googlegroups.com

Kevin,

I value you opinion and you know I am using your Delphi wrapper but I disagree in this case.

Where does it end, maybe with the predominant development languages, C#.Net, VB.Net, PHP.

Since I read that PHP is on over 50 percent of the web sites of the world that would seem to

me to be a good business decision.

If you want application developers to write programs for your database you provide connectivity.

Are you really saying that application developers should write wrappers around the QM Library

written in C. They won’t do it, they will just use another database.

George

From: Kevin Powick

Sent: Wednesday, May 09, 2012 9:24 AM

To: ope...@googlegroups.com

Subject: Re: Problem with QMPHP Subroutine

--
You received this message because you are subscribed to the Google Groups "OpenQM" group.

To view this discussion on the web, visit https://groups.google.com/d/msg/openqm/-/mWgnopvNxuQJ.

Kevin Powick

unread,

May 9, 2012, 11:02:25 AM5/9/12

to ope...@googlegroups.com

On Wednesday, 9 May 2012 10:38:58 UTC-4, grs wrote:

Where does it end, maybe with the predominant development languages, C#.Net, VB.Net, PHP.

What about Java, classic ASP, Mono, JavaScript client, iOS, Android, etc, etc? It's always changing. iOS & Android wouldn't have even been a thought a few years ago, yet mobile development is the hottest thing going right now.

If you want application developers to write programs for your database you provide connectivity.

I think most vendors only provide basic connectivity, such as a native library, ODBC, or OLEDB. It seems to me that the most robust connectivity options come from 3rd parties.

Are you really saying that application developers should write wrappers around the QM Library

written in C. They won’t do it, they will just use another database.

3rd parties that believe there is a market for such options should develop the connectivity libraries, or enthusiastic people can do it themselves. Since we've seen so little of either, one might conclude that either there really isn't much demand, or developers actually are wrapping the libraries themselves. It's not that hard. Using an external library/dll is a pretty common exercise for developers.

If a developer's decision to use a particular database hinges on DB vendor provided connectivity for their development language of choice, then the type of database is likely not integral to the project.

And just for the record. I think that native PHP connectivity to any database is both poor design and a security issue. PHP should be "talking" to a middle tier application server.

--

Kevin Powick

Tony Gravagno

unread,

May 9, 2012, 5:34:42 PM5/9/12

to Ope...@googlegroups.com

From: mg.ryder

> What we require now is the similar thing in QM so that you can
> write a program in basic and it gets converted to javascript.

There are many solutions for converting one language to another, but I
think most developers prefer having native code interoperate well with
various environments.

For this, perhaps mvScript would be of interest to some developers.
Created by Brian Leach, I believe mvScript is only supported for U2,
but Brian might be coerced or cajoled into porting to QM.
http://www.brianleach.co.uk/pages/mvscript.htm
Note from this code sample that it's sort of like Coyote, sort of like
PHP, sort of like classic ASP:

<td align="right" width="212"><b>Author Search :</b></td>
<td><select id="author" name="author">
<option selected value="">(none)</option>

<%
Dc = DCount(AuthorIds,@FM)
For I = 1 To Dc
Crt '<option
value="':AuthorIds<I>:'">':AuthorNames<I>:'</option>'
Next
%>
</select>
</td>

T

Tony Gravagno

unread,

May 9, 2012, 5:34:42 PM5/9/12

to Ope...@googlegroups.com

While I understand George's focus, I completely agree with Kevin on this.

Every language binding provided by MV DBMS companies has some inadequacy. After months of waiting for changes we always get an option which is still not completely adequate, but we need to measure our sense of need with our sense of endurance to justify our request to the upline and then wait for their response. With open source language bindings it's all in the open. We can get what we want immediately if know the language (most likely since we code in the languages for which we request the bindings). And if we don't want to deal with bindings there are a wealth of people here who would gladly accept a "token of gratitude" to maintain open source code.

Like Kevin, I don't want the DBMS providers to spend their time focusing on the language or protocol of the month. I want them focused on making a better database. We can do the former, we can't do the latter. The more time they spend trying to figure out Java or PHP, the less time they're spending on DBMS security, performance, and extensibility tools which allow us to bind even more tightly into their platform.

Also as Kevin said, the language bindings we have are adequate, and there are people willing to support them, if only there were more demand. Frankly I think we see so little interest in language bindings that it's not worth it for anyone to really focus on them - and no reason for Ladybridge to adopt them. What we should have (might already exist somewhere) is a single web page that links to the source for each language binding. There should be an issue tracker for each binding so that we all know what issues are open, and so that anyone can try their hand at addressing issues. Right now each binding is managed completely different (as this sort of thing usually is) and there is no "cohesion" amongst the various libraries. I'd be happy to offer the issue tracker from my site for this, but I doubt it would get much use.

T

Reply all

Reply to author

Forward