headers
Don Cohen | 2 Feb 2011 23:49
Favicon

new bug in MT


(all bug reports related to MT go to -devel, right?)

This was an unpleasant surprise.  I've just made a small improvement
to my debug server.  The new code is below.  The difference is that
in addition to debugging an existing thread you can create a new one.
I find that in the new thread, if I enter (mt::list-threads) I get
a segfault!  The old threads don't do that.

I'm afraid I'm building up a backlog of bugs to be fixed when cvs
returns.  I think the current list includes, in addition to this one,
 performance change over last 10 years
 bug in loop? 

====
(defvar *debug-server-port* 1234)
(defun show-socket-addrs(socket) 
  (multiple-value-bind 
      (local-host local-port) 
      (socket:socket-stream-local socket) 
    (multiple-value-bind 
        (remote-host remote-port) 
        (socket:socket-stream-peer socket) 
      (format t "~&Connection: ~S:~D -- ~S:~D~%" 
              remote-host remote-port local-host local-port)))) 

(defun debug-server() 
  (let ((server (socket:socket-server *debug-server-port* 
                                      :interface "localhost"))) 
       (unwind-protect
(Continue reading)

Permalink | Reply | 3 comments |
headers
Vladimir Tzankov | 3 Feb 2011 08:54
Picon

Re: new bug in MT

On 2/3/11, Don Cohen <don-sourceforge-xxz <at> isis.cs3-inc.com> wrote:
>
> (all bug reports related to MT go to -devel, right?)
yes

> This was an unpleasant surprise.  I've just made a small improvement
> to my debug server.  The new code is below.  The difference is that
> in addition to debugging an existing thread you can create a new one.
> I find that in the new thread, if I enter (mt::list-threads) I get
> a segfault!  The old threads don't do that.

I cannot reproduce the problem (tested on 32bit osx & linux and 64 bit osx).
Can you run the whole thing under gdb and paste here the stack trace
of segfaulted thread?

Vladimir

------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
February 28th, so secure your free ArcSight Logger TODAY! 
http://p.sf.net/sfu/arcsight-sfd2d
_______________________________________________
clisp-devel mailing list
clisp-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/clisp-devel
Permalink | Reply | 2 comments |
headers
Don Cohen | 3 Feb 2011 09:20
Favicon

Re: new bug in MT

Vladimir Tzankov writes:
 > On 2/3/11, Don Cohen <don-sourceforge-xxz <at> isis.cs3-inc.com> wrote:
 > >
 > > (all bug reports related to MT go to -devel, right?)
 > yes
 > 
 > > This was an unpleasant surprise.  I've just made a small improvement
 > > to my debug server.  The new code is below.  The difference is that
 > > in addition to debugging an existing thread you can create a new one.
 > > I find that in the new thread, if I enter (mt::list-threads) I get
 > > a segfault!  The old threads don't do that.
 > 
 > I cannot reproduce the problem (tested on 32bit osx & linux and 64 bit osx).
 > Can you run the whole thing under gdb and paste here the stack trace
 > of segfaulted thread?
 > 
 > Vladimir

I hope this is what you want.  I don't have a very strong idea of what
I'm doing here.  I notice that my first copy/paste added some spaces
to the ends of lines, which ended up causing a format error.
The original error was on old linux 32 bit, this is new linux 64 bit.
Anyway, if this isn't what you want, tell me how to fix it.

(gdb) run
Starting program: /tmp/ap5-2.49+MT 
[Thread debugging using libthread_db enabled]
STACK size: 98222 [0x7ffff2140e00 0x7ffff2081090]
[New Thread 0x7ffff2080700 (LWP 2364)]
  i i i i i i i       ooooo    o        ooooooo   ooooo   ooooo
(Continue reading)

Permalink | Reply | 1 comment |
headers
Vladimir Tzankov | 3 Feb 2011 13:03
Picon

Re: new bug in MT

On 2/3/11, Don Cohen <don-sourceforge-xxz <at> isis.cs3-inc.com> wrote:
> .....
> #64 0x0000000000484b32 in handle_pending_interrupts () at ../src/spvw.d:4547
> #65 0x000000000046b9f9 in allocate_iarray (flags=55 '7', rank=1, type=30)
>     at ../src/spvw_typealloc.d:322
> #66 0x00000000005449eb in init_reader_low (thr=0x7fffe4001fd0)
>     at ../src/io.d:519
> #67 0x00000000006ad30e in thread_stub (arg=0x7fffe4001fd0)
>     at ../src/zthread.d:260
> #68 0x000000309e206d5b in start_thread () from /lib64/libpthread.so.0
> #69 0x000000309dae4a7d in clone () from /lib64/libc.so.6

Thanks.
While I still cannot reproduce it - the above call stack shows the
problem. Thread is being interrupted too early - before it's low-level
initialization. While fixing this - another problem with deferred
interrupts was revealed.

I fixed both issues but sf cvs is still down :(.

Vladimir

------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
February 28th, so secure your free ArcSight Logger TODAY! 
http://p.sf.net/sfu/arcsight-sfd2d
_______________________________________________
clisp-devel mailing list
(Continue reading)

Permalink | Reply | 0 comments |
headers
SourceForge.net | 6 Feb 2011 06:20
Picon
Favicon

[ clisp-Bugs-3153786 ] Website error

Bugs item #3153786, was opened at 2011-01-09 20:13
Message generated for change (Comment added) made by sf-robot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3153786&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: web pages
>Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: guiler (guiler)
Assigned to: Sam Steingold (sds)
Summary: Website error

Initial Comment:
Access to certain parts of the implementation notes is not working. 
Example: http://www.gnu.org/software/clisp/impnotes/socket.html
Breaks with the following error: [an error occurred while processing this directive]

----------------------------------------------------------------------

>Comment By: SourceForge Robot (sf-robot)
Date: 2011-02-06 05:20

Message:
This Tracker item was closed automatically by the system. It was
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sam Steingold | 13 Feb 2011 05:54
Picon

clisp MT & summer of code

Vladimir,
I think we should create a clisp/mt project for the google Summer of Lisp.
IIUC, the only remaining hurdle is MT-safe hash tables, and this sounds
like a good student project.
Could you please write a brief description of what needs to be done?
Thanks!
--

-- 
Sam Steingold (http://sds.podval.org/) on Ubuntu 10.04 (lucid)
http://memri.org http://thereligionofpeace.com http://mideasttruth.com
http://truepeace.org http://iris.org.il http://pmw.org.il http://camera.org
XFM: Exit file manager? [Continue] [Cancel] [Abort]

------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
clisp-devel mailing list
clisp-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/clisp-devel
Permalink | Reply | 1 comment |
headers
Vladimir Tzankov | 14 Feb 2011 20:09
Picon

Re: clisp MT & summer of code

IMO, the only major thing left to be implemented are thread safe hash tables.
There are two approaches to accomplish this:
1. have lock on hash tables operations (e.g. add :synchronized param
to make-hash-table and ensure no segfault may happen with or without
it).
2. re-implement entirely hash tables.

(1) while easier is not good according to me. This will cause
performance issues in clos (internally it uses hash tables) - even
make-instance should (most probably) obtain lock internally.
(2) is the way to go, IMO. I think we should replace current hash
tables with lock-free open-addressing ones like described in:
http://www.azulsystems.com/events/javaone_2007/2007_LockFreeHash.pdf.
CCL hash tables implementation is based on this as well.
The hardest part in this reimplementation is integration with GC
because of weak relations.
I've started to implement (2) but in last year I had almost no free
time to spend on it :(.

There will be more issues with mt of course - but not so major ones as
hash tables.

Vladimir

PS:  currently there is problem with generational gc and heap holes
filling - hope this week to fix it. the problem can be easily observed
when some threads perform socket i/o from slow server and other worker
threads trigger GC frequently.

On 2/13/11, Sam Steingold <sds <at> gnu.org> wrote:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sam Steingold | 15 Feb 2011 16:10
Picon

Re: clisp proposal for google summer of code

Hi,

> * Alin-Florin Rus-Rebreanu <argoybpx <at> tznvy.pbz> [2011-02-15 15:34:18 +0200]:
>
> First of all sorry if this it bothers you that I've sent this as a
> private email.

good news are welcome on any medium, although it is best to use a
mailing list.
clisp-devel is the best venue, please subscribe and reply there.

> I would be very interested in working on GNU CLISP on the
> multithreading interface in or outside GSoC if someone is willing to
> mentor this.

we will be delighted to!
Vladimir is our MT expert; he wrote most of it.
He should be answering you questions about CLISP MT design.
I will do my best helping you with various lesser issues.
Bruno is our "elder statesman".

> I was a student in GSoC 2010 [1] as part of RTEMS and I implemented
> the support for posix asynchronous input output for their system
> (aio_*() and lio_listio()) so I have a pretty good understanding of
> the multithreading stuff required for such a project. I presented 2
> implementation one based on the glibc desing and one redesinged by me
> which is almost fully integrated in RTEMS, it only lacks the
> lio_listio LIO_NOWAIT stuff on which I'm working right now.
>
> I'm a 2nd year student in software engineering.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Alin-Florin Rus-Rebreanu | 15 Feb 2011 17:12
Picon
Gravatar

Re: clisp proposal for google summer of code

On Tue, Feb 15, 2011 at 5:10 PM, Sam Steingold <sds <at> gnu.org> wrote:
> Hi,
>
>> * Alin-Florin Rus-Rebreanu <argoybpx <at> tznvy.pbz> [2011-02-15 15:34:18 +0200]:
>>
>> First of all sorry if this it bothers you that I've sent this as a
>> private email.
>
> good news are welcome on any medium, although it is best to use a
> mailing list.
> clisp-devel is the best venue, please subscribe and reply there.
>
>> I would be very interested in working on GNU CLISP on the
>> multithreading interface in or outside GSoC if someone is willing to
>> mentor this.
>
> we will be delighted to!
> Vladimir is our MT expert; he wrote most of it.
> He should be answering you questions about CLISP MT design.
> I will do my best helping you with various lesser issues.
> Bruno is our "elder statesman".
>
>> I was a student in GSoC 2010 [1] as part of RTEMS and I implemented
>> the support for posix asynchronous input output for their system
>> (aio_*() and lio_listio()) so I have a pretty good understanding of
>> the multithreading stuff required for such a project. I presented 2
>> implementation one based on the glibc desing and one redesinged by me
>> which is almost fully integrated in RTEMS, it only lacks the
>> lio_listio LIO_NOWAIT stuff on which I'm working right now.
>>
(Continue reading)

Permalink | Reply | 3 comments |
headers
SourceForge.net | 15 Feb 2011 19:19
Picon
Favicon

[ clisp-Bugs-3182597 ] WRITE-BYTE-SEQUENCE :no-hang t => error

Bugs item #3182597, was opened at 2011-02-15 18:19
Message generated for change (Tracker Item Submitted) made by donc
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3182597&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Don Cohen (donc)
Assigned to: Nobody/Anonymous (nobody)
Summary: WRITE-BYTE-SEQUENCE :no-hang t => error

Initial Comment:
[3]> (EXT:WRITE-BYTE-SEQUENCE #(1) f :no-hang t) 
   *** - WRITE-BYTE-SEQUENCE on  
         #<OUTPUT BUFFERED FILE-STREAM (UNSIGNED-BYTE 8) #P"/tmp/out1"> is  illegal  
works when array is element-type (unsigned-byte 8)
(the bug is that it does not work for other types)
same problem for unbuffered streams

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=101355&aid=3182597&group_id=1355
(Continue reading)

Permalink | Reply | 0 comments |

Gmane