Steve,
Indeed a kernel oops can happen. I am not going to in detail explain,
but I can tell you that I have seen it happen with dar (Linux backup
software) using zlib. This has been confirmed by the dar community.
Regarding a sheltered life, no I have not such a life. I work with
software support and design. I know that bugs are there in every
software. When doing troubleshooting, identifying bugs is an essential
thing. Figuring out if the customer has a messed up environment (like I
might have on my Itanium system), or if the problem they are
experiencing is due to a bug , is part of the troubleshooting.
I am not at all looking for a bug-free software. There is no such thing.
However, when I am faced with a problem of a segfault I don't
immediately suspect that it is a bug as basic as some conf files
missing. I first assume that there is something wrong with my
environment (compiler flags and stuff). Then I suspect there is a lack
of Itanium support in the code. Specially as I have seen segfaults when
building well established applications as Mozillla and kde on Itanium.
For Mozilla there was a lack of support for Itanium and they fixed that
later.
Now I am really curious as to why I stirred up so many feelings when I
pointed out that a software shouldn't segfault from the lack of some
configuration files. I honestly didn't believe that Asterisk had this
issue. Missing files leading to segfaults was so far out. In my case it
didn't help generating those files. In my case the segfaults were not
caused by those missing files.
When it comes to a propper installation, I tried this this afternoon on
a regular Intel SuSE 9.3 box. It seems to work just fine. I don't
consider anybody that uses and promotes Open Source software an idiot. I
am really sorry if I said something that made you feel that way.
I have gotten all the pointers I could ask for currently. I have some
further troubleshooting to carry out. If you don't have any information
about compiling the GSM codecs on Itanium I will not reply to any
further posting. Polluting this mailing list with this type of endless
discussions about things that don't have any relevance to the product
doesn't make anybody happy.
Thanks,
// Jonas
Steve Underwood wrote:
Jonas Arndt wrote:
Dave,
A segmentation fault is usually caused by the program writing in a
memory area that is not allocated (it could be a result of the
optimizer sometime as well). That means that it can potentially
overwrite code that are executing there. In worst case scenario you
could even cause a kernel Oops. A software that discovers that it is
missing a conf file will obviously have a potential of not working.
However, instead of writing in a memory area that it has not
allocated, it should inform about the situation in a log file
A kernel oops instead of a segfault? What kind of buggy OSes are you
used to? Crazy memory access should only cause segfaults. The ability
of an application to cause an oops would be considered a *very*
serious OS bug.
Programs should not segfault when they have bad or missing config
files. However, a large percentage do. If you haven't realised that
you must have lived a sheltered life. :-)
Now, if you are putting a software on the market that would take down
your system just because you are missing or having an incorrect
configuration file, you will find a lot of people seeing that as a
bug. Imagine ntp segfault and coredump just because the /etc/ntp.conf
is not there.
It can't bring down the system. Only the application itself.
I think my problem is caused by the 32 versus 64 bits difference on
Itanium. Belive me, I have seen this before.
Do you realise that Asterisk runs on various 64 bit machines? x86_64,
PPC, etc.
Anybody out there with experience of compiling this animal on Itanium?
By the way, I just built it and ran it on another architecture.
Without the conf files and there was no segmentation fault.
So what. This means nothing.
What not try a proper installation, and see what happens. Just to keep
the rest of us idiots who haven't a clue about config files and proper
operation happy.
Regards,
Steve
_______________________________________________
Asterisk-Users mailing list
[email protected]
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
[email protected]
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
