----- original message -------- Betreff: Re: [directfb-dev] libfusion race condition Gesendet: Fri, 19 May 2006 Von: "Denis Oliver Kropp" <[EMAIL PROTECTED]>
> Ben Willers wrote: > > hi, > > > > i just wrote two little applications, using libfusion for IPC. > > they seem to run into an SIGSEGV under certain conditions. > > Do you see the signals in gdb only? no, they're also visible under normal conditions. > > > the debug/trace log 1st execution : > > process with pid 20901 is the client > > (-) [Main Thread 12.559] (20901) Fusion/Main: -> done. > (0x805f2b0) > > (-) [Main Thread 12.559] (20901) Fusion/Arena: entering arena 'kitv' > (joining) > > (-) [Fusion Dispatch 12.559] (20900) Fusion/SHMPool: > fusion_shm_pool_allocate( 0x200040b0, 140, unclear, 0xb5deee98 ) > > (-) [Fusion Dispatch 12.559] (20900) Fusion/SHMHeap: > _fusion_shmalloc( 0x28614000, 140 ) > > (-) [Fusion Dispatch 12.559] (20900) Fusion/SHMHeap: > _fusion_shmalloc( 0x28614000, 4096 ) > > (-) [Fusion Dispatch 12.559] (20900) Fusion/SHMHeap: > morecore( 0x28614000, 4096 ) > > (-) [Fusion Dispatch 12.559] (20900) Fusion/SHMHeap: > align( 0x28614000, 4096 ) > > (-) [Fusion Dispatch 12.559] (20900) Fusion/SHMHeap: > __shmalloc_brk( 0x28614000, 4096 ) > > (-) [Fusion Dispatch 12.559] (20900) Fusion/SHMHeap: > -> remapped (28672 -> 32768) > > (-) [Fusion Dispatch 12.559] (20900) Fusion/SHMPool: > fusion_shm_pool_allocate( 0x2000406c, 116, clear, 0xb5deee98 ) > > (-) [Fusion Dispatch 12.559] (20900) Fusion/SHMHeap: > _fusion_shmalloc( 0x28513000, 116 ) > > (-) [Fusion Dispatch 12.560] (20900) Fusion/SHMPool: > fusion_shm_pool_allocate( 0x2000406c, 102, unclear, 0xb5deee98 ) > > (-) [Fusion Dispatch 12.560] (20900) Fusion/SHMHeap: > _fusion_shmalloc( 0x28513000, 102 ) > > (-) [Fusion Dispatch 12.560] (20900) Fusion/SHMPool: > fusion_shm_pool_allocate( 0x200040b0, 80, unclear, 0xb5deee28 ) > > (-) [Fusion Dispatch 12.560] (20900) Fusion/SHMHeap: > _fusion_shmalloc( 0x28614000, 80 ) > > (!) [20901: 12.560] --> Caught signal 11 (at 0x2861b004, invalid > address) <-- > > The problem here is that the message for remapping the shared memory > file has not been processed at the time of the access to the new block. > > Adding a sleep() just gave the other process enough time. > Using sched_yield() should do the same. > > > the debug/trace log 2nd execution : > > now 20908 is the client > > (-) [Main Thread 16.084] (20908) Fusion/Arena: entering arena 'kitv' > (joining) > > (-) [Fusion Dispatch 16.084] (20900) Fusion/SHMPool: > fusion_shm_pool_allocate( 0x200040b0, 140, unclear, 0xb5deee98 ) > > (-) [Fusion Dispatch 16.084] (20900) Fusion/SHMHeap: > _fusion_shmalloc( 0x28614000, 140 ) > > (-) [Fusion Dispatch 16.084] (20900) Fusion/SHMPool: > fusion_shm_pool_allocate( 0x2000406c, 116, clear, 0xb5deee98 ) > > (-) [Fusion Dispatch 16.084] (20900) Fusion/SHMHeap: > _fusion_shmalloc( 0x28513000, 116 ) > > (-) [Fusion Dispatch 16.084] (20900) Fusion/SHMPool: > fusion_shm_pool_allocate( 0x2000406c, 102, unclear, 0xb5deee98 ) > > (-) [Fusion Dispatch 16.084] (20900) Fusion/SHMHeap: > _fusion_shmalloc( 0x28513000, 102 ) > > (-) [Screen Update 16.084] (20899) SDL/Updates: -> > unlocking dfb surface... > > (-) [Screen Update 16.084] (20899) Core/Surface: > dfb_surface_unlock( 0x20016460, front ) > > (-) [Screen Update 16.084] (20899) Core/Surface: -> > system/video count: 1/0 before > > (-) [Screen Update 16.084] (20899) Core/Surface: -> > system/video count: 0/0 after > > (-) [Screen Update 16.084] (20899) SDL/Updates: -> > unlocking sdl surface... > > (-) [Screen Update 16.084] (20899) SDL/Updates: -> calling > SDL_UpdateRect()... > > (-) [Fusion Dispatch 16.086] (20897) Fusion/SHMPool: > fusion_shm_pool_deallocate( 0x200000b0, 0x20115c80 ) > > (-) [Fusion Dispatch 16.086] (20897) Fusion/SHMHeap: > _fusion_shfree( 0x20111000, 0x20115c80 ) > > (-) [Screen Update 16.087] (20899) SDL/Updates: -> > unlocking sdl lock... > > (-) [Screen Update 16.087] (20899) SDL/Updates: -> done. > > (*) Direct/Interface: Loaded 'JPEG' implementation of > 'IDirectFBImageProvider'. > > (-) [Main Thread 16.087] (20908) Core/Layers: > dfb_layer_get_active_context (SDL Primary Layer) > >>> works fine now<< > > In this run the heap doesn't need to be resized/remapped for the > allocation. > > > > Usually, these segfaults are caught and cured so that the program > continues after remapping the file from the signal handler. > > That's dirty, right. My proposed solution is to integrate the > shared memory heap management into Fusion which can either remap > the heap in all Fusionees synchronously or use page faults and > handle them in the kernel. sounds reasonable. i can't help coding anything at the moment though. > > -- > Best regards, > Denis Oliver Kropp > > .------------------------------------------. > | DirectFB - Hardware accelerated graphics | > | http://www.directfb.org/ | > "------------------------------------------" > --- original message end ---- thanks, ben _______________________________________________ directfb-dev mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
