Open GoogleCodeExporter opened 9 years ago
FWIW: I think he was testing this on my compiled plv8 using in PostgreSQL
9.3beta1 EDB 64-bit since he left note here too:
http://www.postgresonline.com/journal/archives/305-PostgreSQL-9.3-extension-trea
ts-for-windows-users-plV8.html
I was able to replicate the issue on my 32-bit/64-bit 9.3beta1 EDB and mingw
installs (plv8 1.4). As well as my 9.2 variants (which are using plv8 1.3
mingw compiled)
so not sure if windows only issue or not: Here is script I used to crash:
CREATE OR REPLACE FUNCTION v8_test_throw() RETURNS float AS
$$
return 1/a;
$$
LANGUAGE plv8;
SELECT v8_test_throw(); --gives expected error: ERROR: ReferenceError: a is
not defined
CREATE OR REPLACE FUNCTION v8_test_catch_throw() RETURNS void AS
$$
try {
plv8.execute('select * from v8_test_throw()');
}
catch(e){
plv8.elog(ERROR, 'Error');
}
$$
language plv8;
SELECT v8_test_catch_throw(); -- crashes service
The logs show this:
STATEMENT: SELECT v8_test_throw();
terminate called after throwing an instance of 'pg_error'
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
LOG: server process (PID 5228) exited with exit code 3
DETAIL: Failed process was running: SELECT v8_test_catch_throw();
LOG: terminating any other active server processes
Original comment by reg...@arrival3d.com
on 23 May 2013 at 12:56
One additional observation. Only seems to be an issue if calling a v8 function
taht throws an error. I can write an SQL like this:
CREATE OR REPLACE FUNCTION v8_test2_catch_throw() RETURNS void AS
$$
try {
plv8.execute('select generate_series(1,10)/0');
}
catch(e){
plv8.elog(ERROR, 'There was an error, please call me ', e);
}
$$
language plv8;
SELECT v8_test2_catch_throw();
Just gives below notice:
ERROR: Error: There was an error, please call me Error: division by zero
DETAIL: v8_test2_catch_throw() LINE 6: plv8.elog(ERROR, 'There was an error,
please call me ', e);
Original comment by reg...@arrival3d.com
on 23 May 2013 at 1:10
also try to cal this
throw new Error('Error');
catch potential errors in every function causes degradation of performance.
I use one proxy function to call any others and need only to catch error in the
first function and need the ability to throw exceptions in any function.
Original comment by vovapjat...@gmail.com
on 23 May 2013 at 2:55
another man reported in a forum the same crash with
server v9.2
plv8 v1.3
Original comment by vovapjat...@gmail.com
on 23 May 2013 at 2:57
I use the script which crases my server
CREATE OR REPLACE FUNCTION v8_test_throw() RETURNS float AS
$$
//plv8.elog(EXCEPTION , "Error");
throw new Error('Error');
$$
LANGUAGE plv8;
CREATE OR REPLACE FUNCTION v8_test_catch_throw() RETURNS json AS
$$
try{
var res = plv8.execute('set role test;' +
'select * from v8_test_throw()');
.....
} catch(e) {
return {"result": "error"};
}
$$
language plv8;
Original comment by vovapjat...@gmail.com
on 23 May 2013 at 3:10
Hmm, it doesn't happen in my Mac. The exception handling in windows has been
not good...
Original comment by umi.tan...@gmail.com
on 24 May 2013 at 6:18
I was afraid of that. Well at least it happens both under pure mingw and when
I run in VC EDB so easier for me to debug.
I'll try to debug it with gdb to see where it is failing. Which version of V8
are you runnning? I'm running 3.14.5 or you think that doesn't matter.
I've been battling similar issues of late with PostGIS when it throws errors --
though those ones only happen in EDB build (using mingw binaries) and
everything works fine under pure mingw so might be different issue.
Original comment by reg...@arrival3d.com
on 24 May 2013 at 11:50
Umi,
I just tried the one that VovaPjat and that ACTUALLY doesn't crash on my
mingw32 or my 9.2 32-bit edb (My 64-bit install is a bit older and doesn't show
the crash but either just doesn't show the catch error shows json error
instead). I suspect it might be the code that was left out that is crashing on
that.
VovaPjat -- can you please state the OS, SELECT version(); of postgres you are
running on. I assume the ..... means you have additional code you left out.
Can you confirm it crashes without the extra code.
Umi,
However the example I posted earlier does crash on all my systems. Can you try
that one on your mac?
as I recall the degradation in performance of throw is a V8 issue -- I've seen
that issue mentioned in v8 forums.
Original comment by reg...@arrival3d.com
on 24 May 2013 at 12:12
Windows Server 2008 R2 64-bit
PostgreSQL 9.3beta1, compiled by Visual C++ build 1600, 64-bit
V8 - version:1.4.0
confirm - there is above the code crases my server without extracode
Original comment by vovapjat...@gmail.com
on 24 May 2013 at 12:29
Ah okay I see what's different about the way I'm running it. I was running it
on a server without an account called "test".
It seems to only crash if the account called "test" exists (and doesn't seem to
matter if that account is a super user or not)
Original comment by reg...@arrival3d.com
on 24 May 2013 at 1:20
[deleted comment]
no, even without "set role test;" it crashes in my case
Original comment by vovapjat...@gmail.com
on 24 May 2013 at 9:34
Yah I realized after i wrote that it was the set role test preventing it from
crashing on my end. Because the set role test was triggering a correctly
caught error before it hit the plv8 function call. So works fine if none-plv8
rasies an error in a execute, just not if another plv8 raises an error.
Original comment by reg...@arrival3d.com
on 25 May 2013 at 3:09
The same behavior I have with 9.2 ver.(64-bit) of PostgreSQL by EnterpriseDB
and 9.2 ver of plv8js
Original comment by vovapjat...@gmail.com
on 7 Jun 2013 at 3:37
It happens in 32-bit too actually (both pure mingw64 and also using the lib in
9.2edb). Haven't had time to revisit. I tried building v8 with gyp instead of
scons. scons was officially removed and I got a gyp compiled build under
mingw64, but can't figure out how to link it with plv8 since it gave me only
static libs instead of dlls.
anyrate based on the little I know I'm suspecting it might have something to do
with this:
http://stackoverflow.com/questions/15670169/what-is-difference-between-sjlj-vs-d
warf-vs-seh
http://msdn.microsoft.com/en-us/library/windows/desktop/ms680657%28v=vs.85%29.as
px
Right now I am using sjlj error handling build. I'm experimenting with Mingw64
GCC 4.8 (with SEH handling) but haven't got a chance to recompile v8 using
that. I suspect that might do a better job of these error handling issues than
the sjlj I am currently using.
Original comment by lr1234...@gmail.com
on 9 Jun 2013 at 10:20
This makes me think we should probably not use C++ exception in our code, as v8
tries, but it would be a significant code change, so I'm holding it for now but
at some day I'll try to see if we could do so.
Original comment by umi.tan...@gmail.com
on 10 Jun 2013 at 7:19
Okay the good news is that after switching my mingw64 chain to 4.8 and
recompiling v8 and plv8 js under this chain.
At least on my 32-bit this issue goes away both testing against mingw64-w2
compiled postgresql as well as using the same binaries under EDB provided
PostgreSQL 9.2.
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/
Personal%20Builds/rubenvb/gcc-4.8-release/ (I'm using this one
i686-w64-mingw32-gcc-4.8.0-win32_rubenvb.7z)
and for compiling 64-bit this one :
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/
Personal%20Builds/rubenvb/gcc-4.8-release/
(x86_64-w64-mingw32-gcc-4.8.0-win64_rubenvb.7z )
I have to retest on my mingw64-w64. I'm hopeful it will fix the issue there
since recompiling has fixed for example this issue in postgis that only seemed
to be triggered under PG 9.2 edb 64-bit (but not in my mingw92 64-bit build) --
http://trac.osgeo.org/postgis/ticket/2338 )
The thing that is puzzling is the windows 4.8 32-bit binaries still use sjlj
jumping (which makes sense since I don't think 32-bit supports seh) . so maybe
its an additional fix in 4.8 that is helping this particular issue.
That said since I have to package a newer libstd-c++ and libgcc_s_sjlj-1.dll
(for 32-bit) and libgcc_s_seh.dll I'm going to have to do a lot of recompiling
and testing to make sure all is kosher with both PostGIS and v8.
I also still have on my list to recompile using gyp once I figure out how to
link in those new gyp binaries I seem to be generating - that exercise I'll
save for another day.
Original comment by reg...@arrival3d.com
on 13 Jun 2013 at 12:28
I've recompiled with gcc 4.8.0 for 64-bit as well and the new build I have
doesn't seem to exhibit these issues. Unfortunately the libstd seems
incompatible with my old 4.5.4 libstd. Anyrate if you were having this problem
-- please give this 9.2w64 build a try. I tried with both my EDB 9.2.4 and my
mingw 9.2 64-bit gcc 4.8.0 compiled PostgreSQL and seems to work fine and not
have this issue. I'll have the 9.3 shortly too.
http://www.postgresonline.com/downloads/pg92plv8jsbin_w64_1.4.0_gcc4.8.0.zip
Original comment by reg...@arrival3d.com
on 16 Jun 2013 at 1:21
Here is the version compiled against 9.3beta1. Seems to not have the issue
http://www.postgresonline.com/downloads/pg93plv8jsbin_w64_1.4.0_gcc4.8.0.zip
Original comment by reg...@arrival3d.com
on 16 Jun 2013 at 3:07
it works fine
Original comment by vovapjat...@gmail.com
on 16 Jun 2013 at 3:45
https://gist.github.com/joevandyk/952e0698b3d96734324c shows how I can crash
postgresql with plv8.
Running postgresql 9.3.1 with latest plv8 and v8 3.7.12 on ubuntu 12.04.
Original comment by joevan...@gmail.com
on 20 Oct 2013 at 9:32
#21 is another issue than the main topic here, but anyway I think it's fixed by
5e428ab.
Original comment by umi.tan...@gmail.com
on 11 Dec 2013 at 10:09
Original issue reported on code.google.com by
vovapjat...@gmail.com
on 22 May 2013 at 5:26