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?

> 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.

-- 
Best regards,
   Denis Oliver Kropp

.------------------------------------------.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/                 |
"------------------------------------------"

_______________________________________________
directfb-dev mailing list
[email protected]
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev

Reply via email to