Variables and limits

0 views
Skip to first unread message

Semih BUDAK

unread,
Jan 25, 2016, 11:09:01 AM1/25/16
to MOO-...@googlegroups.com
Hello everyone,
I have a few questions about MOO variables:
1. Do they have a limit on how many items they can hold?
2. As far as I'm seeing, my MOO tends to freez whenever I insert too
many items inside a list. Is there any way to fix that?
3. Is there any way to give the memory back to the system, which is
mallocked by the code?
Thanks,
Semih.

Tim van Dijen

unread,
Jan 25, 2016, 11:44:34 AM1/25/16
to MOO-...@googlegroups.com
Semih,

You should have a look at options.h, specifically these lines:
#define DEFAULT_MAX_STRING_CONCAT 64537861
#define DEFAULT_MAX_LIST_VALUE_BYTES 64537861
#define DEFAULT_MAX_MAP_VALUE_BYTES 64537861

This sets the default max to approx. 64 MB, which is actually insanely much.
You can either change the defaults in options.h, which will require you
to recompile the source, or override the default value with a property
on the $server_options object.

Memory is given back to the system automatically after execution
finishes. If not, you may have a memory leak in one of your builtins.
If you don't have any custom builtins, you shouldn't have to worry about
this.. Unless you've found a memleak in (mostly) 25 y/o code, which is
unlikely..

Tim

PS.: Things have been a bit crazy lately, so I haven't had the time to
work on the language thingy... Hopefully,

Op 25-1-2016 om 17:05 schreef Semih BUDAK:

the Prometheus Support

unread,
Jan 30, 2016, 1:40:23 PM1/30/16
to MOO-...@googlegroups.com
Greetings!

I have grabbed the MooSQL extension for Stunt from its MySQL fork of Github.
I'm trying to add the MySQL to an existing source, so I added the needed
info to its makefile.in, and also the moosql.cc/moosql.h files.
However, when I compile, I get a bunch of errorsabout moosql.o.
I did change the MYSQLLIBS definition in makefile.in to point to lib64
instead of lib, since that's where my mysql libraries reside.

I have attached the output of the 'make' command to this email.
Curiously, the MySQL fork of Stunt itself did compile when I tested it.
I'd like to use my original source though, since the custom built-ins I
have created are there and also because it holds more hashing than the
MySQL fork does.

I'd be grateful for any possible help.

Cheers,

--
Con
making.txt

Tim van Dijen

unread,
Jan 30, 2016, 4:42:38 PM1/30/16
to MOO-...@googlegroups.com
I see parse_float and parse_number not defined amongst the errors...
They are in numbers.cc, so numbers.h should be included in moosql.cc...
Check the included library (.h) files in moosql.cc and also run `make
dependencies' before compiling...

Op 30-1-2016 om 19:40 schreef the Prometheus Support:

the Prometheus Support

unread,
Jan 31, 2016, 7:45:17 AM1/31/16
to MOO-...@googlegroups.com
Hey!

I got it to compile to my current source, however...
I think that the moosql.cc or moosql.h file has a memory leak.
Ever since I compiled the SQL extension to my source, the proc_size()
has shown an increase of a few megabytes in process every random amount
of minutes. The time is less than an hour though, and what's noticeable
is that I haven't done anything to cause that.
I used the mysql_connect() and mysql_close() built-ins, and after that
the proc_size() raised again.

I've removed all my custom built-ins to see if they were the problem,
but the memory usage continued to increase without them too.

Would anybody have a newer, or fixed, version of the moosql.cc and
moosql.h files so that it wouldn't leak memory?

Cheers,

--
Con

Tim van Dijen

unread,
Jan 31, 2016, 8:23:17 AM1/31/16
to MOO-...@googlegroups.com
Try running your moo with Valgrind, then run the same test case again..
You might get a hint of where this memory leak is hidden...
I've taken a quick look at the .cc file, but I couldn't find anything...

Op 31-1-2016 om 13:45 schreef the Prometheus Support:

the Prometheus Support

unread,
Jan 31, 2016, 10:09:50 AM1/31/16
to MOO-...@googlegroups.com
OK, I returned to the source I was originally using and just attempted
compiling MySQL into it. I got the file from the original MySQL Stunt
fork of Git.

I did add
#include "numbers.h"
to the moosql.cc and moosql.h files to be sure, yet there were still
errors about it.

I have attached the make output to the email.

Cheers,
--
Con
making.txt

Tim van Dijen

unread,
Jan 31, 2016, 10:50:32 AM1/31/16
to MOO-...@googlegroups.com
The fork you are using also has changes to numbers.h and possibly a
bunch of other files too..
You can't just copy in the moosql.cc/.h files and expect it to work out
of the box. I'm surprised you got it to compile earlier.


Op 31-1-2016 om 16:09 schreef the Prometheus Support:

the Prometheus Support

unread,
Feb 1, 2016, 6:35:41 AM2/1/16
to MOO-...@googlegroups.com
Yup...

I've been playing with the MySQL fork from Git. It seems that it uses
more memory by default than the original Stunt does, and the memory
usage increases a bit at random times.

I'll leave a database on that fork running to see how much the memory
actually increases.

the Prometheus Support

unread,
Feb 1, 2016, 1:08:12 PM2/1/16
to MOO-...@googlegroups.com
OK... I'm baffled.
The original Stunt fork without MySQL keeps its proc_size() at approx.
194 megs, but the StuntMySQL fork started as 233MB, and is now, five
hours later, at 246MB.
Yet I don't get any leak results with Valgrind...

Todd Sundsted

unread,
Feb 1, 2016, 1:24:50 PM2/1/16
to MOO Talk
You won't necessarily see any leaks reported from Valgrind until you quit the server.

Josh Benner

unread,
Feb 1, 2016, 1:31:52 PM2/1/16
to the Prometheus Support, MOO-...@googlegroups.com
This was years ago, but I do recall fixing a memory leak in the MOOSQL code. I'm failing to find that fix apparent in my commit log, but this was converted between version control systems multiple times, and I may not have mentioned the leak.

If you send me a copy of the moosql code, I can run a diff and see if anything suggests itself.
> --
> You received this message because you are subscribed to the Google Groups "MOO Talk" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to MOO-talk+u...@googlegroups.com.
> To post to this group, send email to MOO-...@googlegroups.com.
> Visit this group at https://groups.google.com/group/MOO-talk.
> For more options, visit https://groups.google.com/d/optout.

the Prometheus Support

unread,
Feb 13, 2016, 10:14:16 AM2/13/16
to MOO-...@googlegroups.com
Hello!

I seem to be unable to insert data into MySQL tables. I can create and
drop them, same with databases, but:

;mysql_query(#-7, "insert into accounts (user,pass) VALUE ('" +
me.username + "','" + me.password + "'));")
=> "ERR: You have an error in your SQL syntax; check the manual that
corresponds to your MySQL server version for the right syntax to use
near '˜+½Ûm' at line 1"

Would this have something to do with parsing MOO into SQL? I am sure the
SQL syntax is right.

Cheers,
--
Con

Tim van Dijen

unread,
Feb 13, 2016, 11:18:43 AM2/13/16
to MOO-...@googlegroups.com


Op 13-2-2016 om 16:14 schreef the Prometheus Support:
VALUES

the Prometheus Support

unread,
Feb 13, 2016, 2:28:50 PM2/13/16
to MOO-...@googlegroups.com
Oh fixed it. It needed mysql_Escape_string()

Speaking of that, I have fixed an error in the built-in
bf_mysql_escape_Str. Before, it let you enter anything (intigers,
floats, objects) into the string's place, resulting a server panic. The
fixed built-in code, if anybody needs it, is:

static package bf_mysql_escape_str(Var arglist, Byte next, void *vdata,
Objid progr) {
MYSQL_CONN *wrapper;
const char *string;
if (arglist.v.list[0].v.num == 2) {
Objid oid = arglist.v.list[1].v.obj;
wrapper = resolve_mysql_connection(oid);

// the object number given doesn't correspond to an active
connection
if (wrapper == NULL || wrapper->conn == NULL || wrapper->active
== 0) {
free_var(arglist);
return make_error_pack(E_INVARG);
}
if (arglist.v.list[1].type != TYPE_OBJ) return
make_error_pack(E_INVARG);
if (arglist.v.list[2].type != TYPE_STR)
{
return make_error_pack(E_TYPE);
}
string = arglist.v.list[2].v.str;
} else {
wrapper = NULL;
if (arglist.v.list[1].type != TYPE_STR)
{
return make_error_pack(E_TYPE);
}
string = arglist.v.list[1].v.str;
}

Var end;
char *endStr=NULL;
end.type = TYPE_STR;
endStr = myEscapeStr(wrapper, string);
end.v.str = str_dup(endStr);
free(endStr);
free_var(arglist);
return make_var_pack(end);

}

Reply all
Reply to author
Forward
0 new messages