server crhashes when an exception is occure or new error is thrown

[GoogleCodeExporter]

What steps will reproduce the problem?
1. create function1 which throw new error in its body
2. create function2 which call the first function like plv8.execute('select * 
from function1()')
3. execute function2

What is the expected output? What do you see instead?
I want to catch the error with try/catch

What version of the product are you using? On what operating system?
9.3beta1

Original issue reported on code.google.com by vovapjat...@gmail.com on 22 May 2013 at 5:26

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

no, even without "set role test;" it crashes in my case

Original comment by vovapjat...@gmail.com on 24 May 2013 at 9:34

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

it works fine

Original comment by vovapjat...@gmail.com on 16 Jun 2013 at 3:45

[GoogleCodeExporter]

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

[GoogleCodeExporter]

#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