ERROR: invalid memory alloc request size 18446744073709551613 #60
Comments
|
postgres compiled with --enable-debug ? |
|
No, but I can try that? |
|
Yes, building postgres with debugging support might help |
|
I had the same problem with Lua 5.1 installed with apt on Debian 9 and
Postgres 10.
So I tried with luajit and pllua manually compiled and I didn't have this
problem anymore, on the same platform.
Le 19 nov. 2017 15:25, "Eugene Sergeev" <[email protected]> a écrit :
… Yes, building postgres with debugging support might help
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<https://github.com/pllua/pllua/issues/60#issuecomment-345520593>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAAwSKVoTEA41urTZ37g2Y3pdeWvrV-Fks5s4DpZgaJpZM4QjYzH>
.
|
|
Yeah, this is luajit. I tried with lua, and it gives the same problem, but at a slightly different time. But still, |
|
What I do know is that the rows() iterator accesses the first perhaps 20 rows just fine, but suddenly I get |
|
So it seems to me that only accessing the text columns of the given row gives the error. I tried accessing |
|
|
|
This seems to reproduce the bug I am seeing create database pllua_bug;
\c pllua_bug
create extension if not exists pllua;
drop table test;
create table test as select s, md5(random()::text) from generate_Series(1,500) s;
create or replace function f1()
returns void as $$
for t in _U.get_test:rows() do
print(t.md5)
end
end
do
_U = {
get_test = server.prepare([[
SELECT *
FROM test
]]):save()
}
$$ language plluau;
create or replace function f2()
returns void as $$
for t in _U.get_test:rows() do
print(t.md5)
end
end
do
_U = {
get_test = server.prepare([[
SELECT *
FROM test
]]):save()
}
$$ language plluau;
select * from f1();
select * from f2(); |
|
Above test run on postgres compiled with --enable-debug --enable-cassert |
|
I discussed this in the #postgresql irc channel with bjne. It looks to me like much of pllua's memory management is wrong - this particular bug seems to be the result of shallow-copying Datum values without care for whether the target of a by-reference value is being freed. In particular you can't safely SPI_freetuptable a result set until you no longer have any Datum values that were fetched from the tuples and not copied. |
|
...and for the record, this was the start of rhodiumtoad/pllua-ng |
|
Many thanks for Pllua-ng |
|
Hello everyone! |
|
2^64 is 18446744073709551616, so 2^64 - 1 is 18446744073709551615, etc. Therefore these numbers come up very frequently as a result of underflowing a 64-bit unsigned counter. |
|
Thank you, but what could that mean in case mentioned? The number is somehow understandable for x64 server, but still - mysqli_get_client_stats() [active_connections] is kind of "check the list and tell me how many" it should be 0 or 1 (int) Meanwhile - it still bothers me - is it somehow dangerous for server or for database? Should I keep digging, testing and asking or just getting used to it? |
|
This is not the place to ask these questions. Take it somewhere more appropriate. |
When using prepared statements in _U, I experience weird behavior. I am not able to create a testcase
that reproduces, but what I am seeing is:
Any idea what this is or where I can look to start debugging this?
Running on pllua/pllua master and postgresql 9.5
The text was updated successfully, but these errors were encountered: