[erlang-questions] Re: Debugger fault at startup.

[Michael Richter]

I would agree with this but for the fact that two pre-built Erlang for
Windows (R14B and R13B02) exhibit similar behaviour (but without the
"helpful" message) on a completely different machine.

As for my build, it's a raw untar, ./configure & make & sudo make install.
 I'm not sure how I could possibly screw that up short of mis-spelling
"configure".  I even repeated the process today just to double-check.

On 27 September 2010 19:56, Attila Rajmund Nohl <attila.r.nohl@REDACTED>wrote:

> I've just tested on R14B on SuSE 10 and the wx demo works fine... My
> gut feeling is that your build was not properly built. Or you might
> have a hardware error.
>
> 2010/9/27, Michael Richter <ttmrichter@REDACTED>:
> > After reading Pascal Chapier's message, I tried something else.  From a
> > fresh, unaltered build of R14B on a pretty bog-standard Ubuntu 10.04
> > installation typing "wx:new()." in the shell generates precisely the same
> > crash message.  This leads me to believe that wx is badly broken in R14B.
> >  Trying either "wx:new()." or "debugger:start()." in R14B on a completely
> > standard Windows XP system causes the VM to crash instantly, whether run
> as
> > werl.exe or erl.exe.  I happen to also have R13B02 on that machine and
> the
> > same problem is exhibited there.
> >
> > It looks to me like wx support is really badly broken and has been for
> some
> > time.
> >
> > On 27 September 2010 12:22, Michael Richter <ttmrichter@REDACTED>
> wrote:
> >
> >> So, for the first time I find myself having to fire up the debugger in
> >> Erlang.  Following the user manual, I do this:
> >>
> >> $ erl
> >>
> >> Erlang R14B (erts-5.8.1) [source] [64-bit] [smp:2:2] [rq:2]
> >>> [async-threads:0] [hipe] [kernel-poll:true]
> >>
> >>
> >>> Eshell V5.8.1  (abort with ^G)
> >>
> >> 1> debugger:start().
> >>
> >> beam.smp: malloc.c:3096: sYSMALLOc: Assertion `(old_top == (((mbinptr)
> >>> (((char *) &((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct
> >>> malloc_chunk, fd)))) && old_size == 0) || ((unsigned long) (old_size)
> >=
> >>> (unsigned long)((((__builtin_offsetof (struct malloc_chunk,
> >>> fd_nextsize))+((2 * (sizeof(size_t))) - 1)) & ~((2 * (sizeof(size_t)))
> -
> >>> 1))) && ((old_top)->size & 0x1) && ((unsigned long)old_end & pagemask)
> ==
> >>> 0)' failed.
> >>
> >>                                  Aborted
> >>
> >> $
> >>
> >>
> >> I don't even know where to begin here.  Is there any expert on the
> >> debugger's inner workings that knows both what that means and what can
> be
> >> done about it?
> >>
> >> --
> >> "Perhaps people don't believe this, but throughout all of the
> discussions
> >> of entering China our focus has really been what's best for the Chinese
> >> people. It's not been about our revenue or profit or whatnot."
> >> --Sergey Brin, demonstrating the emptiness of the "don't be evil"
> mantra.
> >>
> >
> >
> >
> > --
> > "Perhaps people don't believe this, but throughout all of the discussions
> of
> > entering China our focus has really been what's best for the Chinese
> people.
> > It's not been about our revenue or profit or whatnot."
> > --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra.
> >
>



-- 
"Perhaps people don't believe this, but throughout all of the discussions of
entering China our focus has really been what's best for the Chinese people.
It's not been about our revenue or profit or whatnot."
--Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra.