agora inbox for pljava-dev@postgresql.org  

help / color / mirror / Atom feed

Subject: [Pljava-dev] stack depth limit exceeded (NOT from infinite	recursion)
Date: Wed, 28 Sep 2005 14:38:27 +0800
Message-ID: <433A3A63.5020405@tokuii.com> (raw)
In-Reply-To: <thhal-0xMUVBOuT8bQDO2T+rESSwPlnTwfAEi@mailblocks.com>
References: <4333C332.3060302@tokuii.com>
	<4333CDF5.9040207@mailblocks.com>
	<thhal-0eGYPBKtj8bQVL/zrUF/3KkUJjDRvrG@mailblocks.com>
	<4333DB16.40904@tokuii.com>
	<4333DD5A.5030707@mailblocks.com>
	<thhal-03nUPBL1j8bQylOUBCGsY1w4DiIhUuA@mailblocks.com>
	<4339F73C.8030106@tokuii.com>
	<433A2D41.2070009@mailblocks.com>
	<thhal-0xMUVBOuT8bQDO2T+rESSwPlnTwfAEi@mailblocks.com>

Thanks a lot Thomas, "set the max_stack_depth to a ridiculously high 
value" appeared to work around the problem for now.  This is the 
quickest solution at the moment and I will try that till I see another 
problem.

Thanks again.

Regards,
Kong

Thomas Hallgren wrote:

> Kong,
> PostgreSQL only defines one stack, and thus one stack_depth_limit. 
> It's not built for multiple threads and at present and PL/Java has no 
> way of telling PostgreSQL that another thread is about to do 
> something. PostgreSQL still thinks it's the same stack, hence the 
> problem. The stack-depth of the other thread is irrelevant. The 
> problem is caused by PostgreSQL comparing the stack_pointer from one 
> stack with the stack_base from another.
>
> You encounter this problem because a thread other then the main thread 
> is the first to encounter a class. That causes the classloader to make 
> an attempt to load the class in that thread. If you can find out what 
> class it is and then reference this class in advance from the main 
> thread, the problem will go away since the main thread will be the one 
> that loads the class.
>
> An alternative to this is to set the max_stack_depth to a ridiculously 
> high value and thus turn of stack checks altogether. I don't think 
> that will cause a major problem anyway. If you run into a 
> stack-overflow, the process will page-fault and terminate.
>
> I know none of those solutions are ideal but until I can convince the 
> PostgreSQL people to provide a function whereby I can set another 
> stack_base, there's nothing else I can do.
>
> Regards,
> Thomas Hallgren
>
> kstian wrote:
>
>> Hi Thomas,
>>
>> Thanks a lot for the info.  I went through reorganizing the installed 
>> jar file and reduced the size of the jar file to contain about 263 
>> required class files (as compared to thousands originally).  Then I 
>> re-ran the 3rd party connection from within pljava again and still 
>> seeing the same 'stack depth limit exceeded' problem.
>>
>> May I know what is the stack depth limit for the second thread that 
>> spawned from pljava?  As of now, I have no idea how to work around 
>> this problem.
>>
>> Thanks so much.
>>
>> Regards,
>> Kong
>>
>> Thomas Hallgren wrote:
>>
>>> OK, I see the problem. The connection spawns a new thread, that 
>>> thread loads classes. And of course, the stack of that thread cannot 
>>> be compared to the stack of the caller thread. PostgresSQL (since 
>>> it's singlethreaded) thinks that you eat a vast amount of stack.
>>>
>>> I'll address this on the PostgreSQL hackers mailing list and see if 
>>> I can convince them to install something that makes it possible to 
>>> temporary shut off the stack-check. A temporary work-around is to 
>>> reference the needed classes before making the connect call. That 
>>> way, the current thread will be the one who loads them.
>>>
>>> Regards,
>>> Thomas Hallgren
>>
>>
>
>
>
>

view thread (7+ messages)

Message-ID: <433A3A63.5020405@tokuii.com>
Permalink:  ../433A3A63.5020405@tokuii.com/
Also on:    postgresql.org/message-id/433A3A63.5020405@tokuii.com

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pljava-dev@postgresql.org
  Subject: Re: [Pljava-dev] stack depth limit exceeded (NOT from infinite	recursion)
  In-Reply-To: <433A3A63.5020405@tokuii.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox