[OpenSIPS-Users] Core Dump

[Nathaniel L Keeling III]

Bogdan,

Please explain what I am doing wrong. From what I am understanding, I 
should be able to issue the make command and everything should compile 
ok, but when I do, I get errors and a unsuccessful compile. When I add 
the option "-mcpu=ultrasparc" I get a successful compile. I have 
included a text file of the output from the compile.

Nathaniel

Bogdan-Andrei Iancu wrote:

>Hi Brian,
>
>Maybe you should consider reporting the crashing you are mentioning (if 
>they are so many as you say), so somebody could fix them - in this case 
>everybody will be happier , I guess.
>
>If it crashes or not it depends a lot of what functionalities (modules) 
>you are using (nobody can claim he tested all the modules in all 
>possible combinations).
>
>For example I'm running opensips.org SIP service with SVN trunk and I do 
>not get any core dumps...and it is an almost 3K lines config...
>
>So, again, if you get crashes, please report them.
>
>Regards,
>Bogdan
>
>PS: if the build is bogus (like in Nathaniel), the runtime will be 
>unstable also - OpenSIPS has a lot of asm code that really depends on 
>arch, so messing the build params may lead to bogus code.
>
>
>
>opensipslist at encambio.com wrote:
>  
>
>>Hello Bogdan,
>>
>>An ven., févr 19, 2010, Bogdan-Andrei Iancu schrieb:
>>  
>>    
>>
>>>opensipslist at encambio.com wrote:
>>>    
>>>      
>>>
>>>>An jeu., févr 18, 2010, Nathaniel L Keeling schrieb:
>>>>      
>>>>        
>>>>
>>>>>I have compiled opensips 1.6.1 on Solaris Sparc 10. I was able to
>>>>>compile successfully by adding the parameter "-mcpu=ultrasparc" to
>>>>>the "DEFS" compile time options in Makefile.defs, but when I
>>>>>execute opensips, it will die with a core dump. It does thru the
>>>>>loading of the modules ok but dies later.
>>>>>
>>>>>        
>>>>>          
>>>>>
>>>>Both Solaris 10 Sparc or Solaris 11 x86 do core dump when trying
>>>>to use OpenSIPS 1.6.1. Nobody has seem to be able to diagnose this
>>>>correctly much less repair the problem.
>>>>
>>>>      
>>>>        
>>>>
>>>How comes ? I know people using 1.6 on sparc + Solaris  :P....
>>>
>>>    
>>>      
>>>
>>I don't know either, but I'm sure that some builds work better
>>than others. This would particularly be the case if the problem
>>code was in a certain module or component which some builds are
>>missing. My build contains almost everything.
>>
>>  
>>    
>>
>>>>If you try the same build parameters to compile 1.6.0 you will
>>>>probably find that it not only compiles correctly but runs without
>>>>core dumping as well. So much for the
>>>>
>>>>    'it is recommended to upgrade, as it provides important
>>>>     stability improvements'
>>>>
>>>>that they write about the 1.6.1 release on the website.
>>>>
>>>>      
>>>>        
>>>>
>>>hmmm... if you see the compiling as stability, maybe you are right....
>>>
>>>    
>>>      
>>>
>>The buildtime is not as problematic as the runtime, which only
>>rarely coredumps on 1.6.0 but quite often on 1.6.1. I can get
>>1.6.0 to coredump as well by forcing OpenSIPS to try writing
>>to TCP connections which don't exist. Being careful with 1.6.0
>>then it is possible to get a few weeks worth of usage with no
>>core dump, maybe more.
>>
>>  
>>    
>>
>>>Now, getting serious... the problem is that since SF trashed the 
>>>compiled farm, we (or at least I) do not have any sparc / solaris 
>>>platform were to test the makefile options or the code...
>>>
>>>    
>>>      
>>>
>>You can do a lot with a single good machine and Xen, but that
>>is maybe food for another thread. It's sad indeed that no Solaris
>>platforms are available for testing.
>>
>>Regards,
>>Brian
>>
>>_______________________________________________
>>Users mailing list
>>Users at lists.opensips.org
>>http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>  
>>    
>>
>
>
>  
>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: opensips1.6.1-errors.txt
Url: http://lists.opensips.org/pipermail/users/attachments/20100222/4e144609/attachment.txt