gmane.comp.lang.erlang.general

Paul Fisher | 3 Jul 17:10

erts design information/experts around?

I sent the following note to erlang-bugs two days ago and have not seen
anyone comment.

> We have a system where we run lots of linked-in driver ports that get
> created/used/closed frequently and sometimes very quickly.  Today when
> several open_port/2, port_command/2 and port_close/1 cycles happened
> rapid succession, a SIGSEGV occurrect in erl_bif_ddl.c:
> 
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 1125235040 (LWP 12087)]
> 0x0000000000449712 in erl_ddll_try_unload_2 (p=0x2aaaab11fc90,
>     name_term=659339, options=46912503328425) at beam/erl_bif_ddll.c:592
> 

This is not the first email about runtime internals that I have sent
which has gone without comment, and so I am wondering if the people with
detailed knowledge of the runtime do not follow these lists.

Is there a better place/way to get in contact?  (What I am really
looking for is a discussion of the overall internals design of the smp
runtime structures, so that I can get a jump start on fixing these types
of thing myself.)

thanks in advance,

--

-- 
paul

_______________________________________________
erlang-questions mailing list

(Continue reading)

headers

Raimo Niskanen | 3 Jul 17:53

Re: erts design information/experts around?

On Thu, Jul 03, 2008 at 10:12:27AM -0500, Paul Fisher wrote:
> I sent the following note to erlang-bugs two days ago and have not seen
> anyone comment.
>  
> > We have a system where we run lots of linked-in driver ports that get
> > created/used/closed frequently and sometimes very quickly.  Today when
> > several open_port/2, port_command/2 and port_close/1 cycles happened
> > rapid succession, a SIGSEGV occurrect in erl_bif_ddl.c:
> > 
> > Program received signal SIGSEGV, Segmentation fault.
> > [Switching to Thread 1125235040 (LWP 12087)]
> > 0x0000000000449712 in erl_ddll_try_unload_2 (p=0x2aaaab11fc90,
> >     name_term=659339, options=46912503328425) at beam/erl_bif_ddll.c:592
> > 
> 
> ???This is not the first email about runtime internals that I have sent
> which has gone without comment, and so I am wondering if the people with
> detailed knowledge of the runtime do not follow these lists.
> 

They are on vacation. We would need both the experts on
SMP and the experts on Windows debugging.

Were it on Unix we would have requested a core dump,
but on Windows I do not know if there is such a thing,
or if there has to be a VisualStudio 8 installation
plus source code on the failing machine. The experts
on Windows debugging would know.

> Is there a better place/way to get in contact?  (What I am really

(Continue reading)

headers

Paul Fisher | 3 Jul 18:11

Re: erts design information/experts around?

On Thu, 2008-07-03 at 17:53 +0200, Raimo Niskanen wrote:
> On Thu, Jul 03, 2008 at 10:12:27AM -0500, Paul Fisher wrote:
> > I sent the following note to erlang-bugs two days ago and have not seen
> > anyone comment.
> >  
> > > We have a system where we run lots of linked-in driver ports that get
> > > created/used/closed frequently and sometimes very quickly.  Today when
> > > several open_port/2, port_command/2 and port_close/1 cycles happened
> > > rapid succession, a SIGSEGV occurrect in erl_bif_ddl.c:
> > > 
> > > Program received signal SIGSEGV, Segmentation fault.
> > > [Switching to Thread 1125235040 (LWP 12087)]
> > > 0x0000000000449712 in erl_ddll_try_unload_2 (p=0x2aaaab11fc90,
> > >     name_term=659339, options=46912503328425) at beam/erl_bif_ddll.c:592
> > > 
> > 
> > ???This is not the first email about runtime internals that I have sent
> > which has gone without comment, and so I am wondering if the people with
> > detailed knowledge of the runtime do not follow these lists.
> > 
> 
> They are on vacation. We would need both the experts on
> SMP and the experts on Windows debugging.

Vacation explains it, thx!

My fault, this is R12B-3 on 64-bit Intel Linux (debian etch).  Also
happens on R12B-2 in the same way.

> > Is there a better place/way to get in contact?  (What I am really

(Continue reading)