Re: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl(3) setting `odd' errno's
Garrett Cooper yanef...@gmail.com writes: #include err.h #include errno.h #include stdio.h #include sys/types.h #include sys/sysctl.h You should always put your sys includes before your non-sys includes, and in any case, sys/types.h should always come first. printf(Errno: %d\n, errno); errx(errno, Error: %s, strerror(errno)); In addition to what everybody else said, errno is not an appropriate value for errx's first argument. Use 1 or EXIT_FAILURE (or one of the macros defined in sysexits.h, but I wouldn't recommend it). Also, you probably want to use err(), not errx(), and *always* compile with -Wall -Wextra, and unless you're going to run gdb on your program, -O2 (which enables additional code analysis) DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
admin jop
hi hackers, is someone that can tell me how mach money can a company pay me each mount for admin a bsd server installed in the company, i will adminthe server remotly, is not a stable jop please can tell me on us dolar -- Leon Chavez Colima, Mexico lazaax ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Confused by segfault with legitimate call to strerror(3) on amd64 / sysctl(3) setting `odd' errno's
Hi Garrett,
On Fri, 16 Jan 2009, Garrett Cooper wrote:
On Fri, Jan 16, 2009 at 12:58 AM, Garrett Cooper yanef...@gmail.com wrote:
On Fri, Jan 16, 2009 at 12:57 AM, Christoph Mallon
christoph.mal...@gmx.de wrote:
Garrett Cooper schrieb:
Good point. I modified the source to do that.
Thanks,
-Garrett
You should reply to all so the discussion stays on the list.
Yeah, that was a goofup on my part. Go-go Gmail web interface!
-Garrett
Hmmm... looks like the strerror issue it could be a serious bug:
Add #include string.h.
Without it you don't get the strerror() prototype, so the return value
defaults to an int. Thus the compiler will truncate the pointer value
to junk. The crash happens when formatting the output.
Compile with -Wall and pay attention to warnings (or use -Werror)
to catch these things.
$.02,
/Mikko
#include errno.h
#include stdio.h
#include sys/stat.h
int
main()
{
struct stat sb;
int o_errno;
if (stat(/some/file/that/doesn't/exist, sb) != 0) {
o_errno = errno;
printf(Errno: %d\n, errno);
err(errno, %s, strerror(o_errno));
}
return 0;
}
[gcoo...@optimus ~]$ ./badfile
Errno: 2
badfile: Segmentation fault: 11 (core dumped)
I rebuilt my kernel and installed it, and I rebuilt world, but
haven't installed it yet though, so let me reboot the amd64 machine
and see what happens (may be a mismatched ABI issue)...
Cheers,
-Garrett
___
freebsd-am...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-amd64
To unsubscribe, send any mail to freebsd-amd64-unsubscr...@freebsd.org
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
gcc 4.3.2 libgcc_s.so exception handling broken?
Hello. I have some C code that's compiled with -fexceptions using the lang/gnat-gcc43 port. I'm on 6.4-RELEASE-p2. A function c_function in the C code takes a callback as an argument. I'm passing this function the address of a function ext_function defined in another language (Ada, to be precise, but it seems to happen with C++ too). The main body of my program is written in this language so C is effectively the foreign code (whatever). If ext_function raises an exception, the exception is NOT propagated through the C code, the process simply exits. To clarify: 1. Ada_program_main calls c_function, passing ext_function as argument. 2. c_function calls ext_function. 3. ext_function raises exception. 4. process exits In this case, the C code lives inside a dynamic library, which is linked against /usr/local/lib/gcc-4.3.2/libgcc_s.so (I never specified this explicity, I'm assuming -fexceptions causes this). If I statically link the C code (so libgcc_s.so isn't involved, I think), the exception is propagated correctly. 1. Ada_program_main calls c_function, passing ext_function as argument. 2. c_function calls ext_function. 3. ext_function raises exception. 4. stack unwinds back to Ada_program_main. 5. Ada_program_main handles exception. Why is it that the code can't unwind the call stack correctly? Is this a bug? The same code seems to work correctly on Debian Lenny with the same compiler. Any help would be appreciated. xw ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Remote kernel debugging in FreeBSD using serial communication
Hi All, I am trying remote kernel debugging in FreeBSD using serial communication. I got the following link. http://www.ibm.com/developerworks/aix/library/au-debugfreebsd.html#list1 My problem is my developing and target system does not have DS25 female port. Anyone have any idea about Remote kernel debugging in FreeBSD using DS9 F/F Serial cable or any other remote debugging idea? Thanks, Kamlesh MS CS CSUS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Remote kernel debugging in FreeBSD using serial communication
On Sat, 17 Jan 2009 17:57:10 PST Kamlesh Patel shilp.ka...@yahoo.com wrote:
Hi All,
I am trying remote kernel debugging in FreeBSD using serial communication. I
got the following link.
http://www.ibm.com/developerworks/aix/library/au-debugfreebsd.html#list1
My problem is my developing and target system does not have DS25 female port.
Anyone have any idea about Remote kernel debugging in FreeBSD using DS9 F/F S
erial cable or any other remote debugging idea?
Get one or more modular kits like the one below:
http://www.cablesnmor.com/modular-kit-db9f-rj45.aspx
Now wire it according to the pinouts here:
http://yost.com/computers/RJ45-serial/index.html
If (in the unlikely event) you have any more RS-232 devices,
you can attach a similar db{9,25}{f,m}-rj45 adapter to each
-- just make sure that on the RJ-45 side signals come out as
specified in the web page above (also reproduced below).
Now you can use a half-twist 8 conductor cable to connect
*any* two such devices. You can even use a 4 or 6 conductor
half-twist cable with the same RJ-45 jacks since the layout
is such that the more important signals are towards the
middle.
1 2 3 4 5 6 7 8
CTS DCD RD SG SG TD DTR RTS
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Remote kernel debugging in FreeBSD using serial communication
On Sat, 17 Jan 2009 17:57:10 -0800 (PST) Kamlesh Patel shilp.ka...@yahoo.com wrote: Hi All, I am trying remote kernel debugging in FreeBSD using serial communication. I got the following link. http://www.ibm.com/developerworks/aix/library/au-debugfreebsd.html#list1 My problem is my developing and target system does not have DS25 female port. Anyone have any idea about Remote kernel debugging in FreeBSD using DS9 F/F Serial cable or any other remote debugging idea? Have you tried following the link about 9-pin null-modem cables on the above page? Is there a particular problem? If you go to PC World, or equivalent, a null modem cable will have 9-pin connectors. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: gcc 4.3.2 libgcc_s.so exception handling broken?
xorquew...@googlemail.com schrieb: Hello. I have some C code that's compiled with -fexceptions using the lang/gnat-gcc43 port. I'm on 6.4-RELEASE-p2. A function c_function in the C code takes a callback as an argument. I'm passing this function the address of a function ext_function defined in another language (Ada, to be precise, but it seems to happen with C++ too). The main body of my program is written in this language so C is effectively the foreign code (whatever). If ext_function raises an exception, the exception is NOT propagated through the C code, the process simply exits. To clarify: 1. Ada_program_main calls c_function, passing ext_function as argument. 2. c_function calls ext_function. 3. ext_function raises exception. 4. process exits In this case, the C code lives inside a dynamic library, which is linked against /usr/local/lib/gcc-4.3.2/libgcc_s.so (I never specified this explicity, I'm assuming -fexceptions causes this). If I statically link the C code (so libgcc_s.so isn't involved, I think), the exception is propagated correctly. 1. Ada_program_main calls c_function, passing ext_function as argument. 2. c_function calls ext_function. 3. ext_function raises exception. 4. stack unwinds back to Ada_program_main. 5. Ada_program_main handles exception. Why is it that the code can't unwind the call stack correctly? Is this a bug? The same code seems to work correctly on Debian Lenny with the same compiler. Any help would be appreciated. xw Are more C functions involved? E.g. is the function pointer passed to qsort(), which lives in libc, which is not compiled with -fexceptions. Look at the stack trace when the exception occurs. In gdb you can use the command catch throw (sic) to break when an exception gets thrown. Conversely you can break at the catcher with catch catch (if it gets this far). ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Remote kernel debugging in FreeBSD using serial communication
On Saturday, 17 January 2009 at 17:57:10 -0800, Kamlesh Patel wrote: Hi All, I am trying remote kernel debugging in FreeBSD using serial communication. I got the following link. http://www.ibm.com/developerworks/aix/library/au-debugfreebsd.html#list1 This article is inaccurate in a number of points, notably building the kernel. I'd recommend that you read the document at http://www.lemis.com/grog/Papers/Debug-tutorial/, which also gives you much more information about the debugging process. My problem is my developing and target system does not have DS25 female port. It doesn't have to be DB25, and it doesn't have to be female. Anyone have any idea about Remote kernel debugging in FreeBSD using DS9 F/F Serial cable or any other remote debugging idea? That should work just as well. There's nothing special about the link. But if you have any alternatives, don't use an async serial cable for kernel debugging. It's glacially slow, and people have had all sorts of problems with it in the course of time. Firewire is much better, and you may even find that the hardware is cheaper. Greg -- See complete headers for address and phone numbers. pgpG8aCfwvUvZ.pgp Description: PGP signature
Re: gcc 4.3.2 libgcc_s.so exception handling broken?
On Sat, 17 Jan 2009, xorquew...@googlemail.com wrote: Hello. I have some C code that's compiled with -fexceptions using the lang/gnat-gcc43 port. I'm on 6.4-RELEASE-p2. A function c_function in the C code takes a callback as an argument. I'm passing this function the address of a function ext_function defined in another language (Ada, to be precise, but it seems to happen with C++ too). The main body of my program is written in this language so C is effectively the foreign code (whatever). If ext_function raises an exception, the exception is NOT propagated through the C code, the process simply exits. I tried a simple example of this in C++ and it works as expected. (I am on 7.0-RELEASE/amd64.) So it isn't completely busted, at least. Can you post an example that exhibits the problem? Ideally, something complete that can be compiled and is as simple as possible. If you can do it with C++ rather than Ada it might be easier, so people don't have to install the Ada compiler. Also please mention the commands you use to compile, and what they output when you compile using -v, and what architecture you are on. -- Nate Eldredge neldre...@math.ucsd.edu ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: gcc 4.3.2 libgcc_s.so exception handling broken?
On 2009-01-18 07:39:51, Christoph Mallon wrote:
Are more C functions involved? E.g. is the function pointer passed to
qsort(), which lives in libc, which is not compiled with -fexceptions.
Look at the stack trace when the exception occurs. In gdb you can use the
command catch throw (sic) to break when an exception gets thrown.
Conversely you can break at the catcher with catch catch (if it gets this
far).
Unfortunately not. That was the first thing I looked at.
Here's the complete test:
/* c_function.c */
#include stdio.h
void
c_function (void (*func)(int x))
{
printf (-- %s enter\n, __func__);
func (23);
printf (-- %s exit\n, __func__);
}
-- ada_main.adb
with interfaces.c;
with ada.text_io;
procedure ada_main is
package c renames interfaces.c;
test_error : exception;
procedure ext_function
(x : in c.int) is
begin
ada.text_io.put_line (-- ext_function c.int'image (x));
raise test_error;
end ext_function;
procedure c_function
(process : access procedure (x : in c.int));
pragma import (c, c_function, c_function);
begin
ada.text_io.put_line (-- ada_main entry);
c_function (ext_function'access);
exception
when test_error =
ada.text_io.put_line (-- ada_main caught test_error);
end ada_main;
Compilation:
gcc43 -o c_function.o -c c_function.c -fPIC -fexceptions -g -W -Werror -Wall
-std=c99 -pedantic-errors -Wno-unused-parameter
gcc43 -shared -Wl,-soname,c_function.so -o c_function.so c_function.o -lc
gcc43 -o ada_main.o -c ada_main.adb -g -fstack-check -gnatwaleFG -gnatVa
-gnato -gnata
gnatbind ada_main.ali
gnatlink -o main-dynamic ada_main.ali c_function.so
gnatbind ada_main.ali
gnatlink -o main-static ada_main.ali c_function.o
$ LD_LIBRARY_PATH=. ldd c_function.so
c_function.so:
libc.so.6 = /lib/libc.so.6 (0x2807d000)
libgcc_s.so.1 = /usr/local/lib/gcc-4.2.3/libgcc_s.so.1 (0x2817)
Test:
$ ./main-static
-- ada_main entry
-- c_function enter
-- ext_function 23
-- ada_main caught test_error
$ LD_LIBRARY_PATH=. ./main-dynamic
-- ada_main entry
-- c_function enter
-- ext_function 23
raised ADA_MAIN.TEST_ERROR : ada_main.adb:15
$ LD_LIBRARY_PATH=. gdb68 ./main-dynamic
(gdb) catch exception
Catchpoint 1: all Ada exceptions
(gdb) b __gnat_os_exit
Breakpoint 2 at 0x805851b: file adaint.c, line 2116.
(gdb) r
Catchpoint 1, ADA_MAIN.TEST_ERROR at 0x08049cda in ada_main.ext_function
(x=23) at ada_main.adb:15
15 raise test_error;
(gdb) bt
#0 __gnat_debug_raise_exception (e=0x8061168) at s-except.adb:48
#1 0x0804b620 in __gnat_raise_nodefer_with_msg (e=0x8061168) at
a-except.adb:830
#2 0x0804b698 in __gnat_raise_exception (e=0x8061168, message=0x8061168)
at a-except.adb:870
#3 0x08049cda in ada_main.ext_function (x=23) at ada_main.adb:15
#4 0x280927ae in c_function (func=0x8049bf8 ada_main.ext_function) at
c_function.c:9
#5 0x08049b5c in ada_main () at ada_main.adb:24
(gdb) c
Breakpoint 2, __gnat_os_exit (status=1) at adaint.c:2116
(gdb) bt
#0 __gnat_os_exit (status=1) at adaint.c:2116
#1 0x0805a41e in __gnat_unhandled_terminate () at raise.c:78
#2 0x0805a1f1 in __gnat_last_chance_handler (exce...@0x8071000) at
a-elchha.adb:138
#3 0x0804ae14 in
ada.exceptions.exception_traces.unhandled_exception_terminate () at
a-exextr.adb:175
#4 0x0804aad2 in ada.exceptions.exception_propagation.cleanupunwind_handler
(uw_version=1, uw_phases=10, uw_eclass=5138137877735301376, uw_exception=0xa,
uw_context=3217024852, uw_argument=0, uw_exceptionF=134587758) at
a-exexpr.adb:369
#5 0x0805c282 in _Unwind_ForcedUnwind_Phase2 (exc=0x806f000,
context=0xbfbfe754) at ../.././..//gcc-4.3.2/libgcc/../gcc/unwind.inc:168
#6 0x0805c4d6 in _Unwind_Resume (exc=0x806f000) at
../.././..//gcc-4.3.2/libgcc/../gcc/unwind.inc:237
#7 0x08049cfa in ada_main.ext_function (x=23) at ada_main.adb:16
#8 0x280927ae in c_function (func=0x8049bf8 ada_main.ext_function) at
c_function.c:9
#9 0x08049b5c in ada_main () at ada_main.adb:24
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: gcc 4.3.2 libgcc_s.so exception handling broken?
On 2009-01-17 23:07:29, Nate Eldredge wrote:
I tried a simple example of this in C++ and it works as expected. (I am on
7.0-RELEASE/amd64.) So it isn't completely busted, at least.
Can you post an example that exhibits the problem? Ideally, something
complete that can be compiled and is as simple as possible. If you can do
it with C++ rather than Ada it might be easier, so people don't have to
install the Ada compiler. Also please mention the commands you use to
compile, and what they output when you compile using -v, and what
architecture you are on.
Hello.
You're right, the C++ example works here. I'm not sure why it didn't before.
Here's a C++ version:
/* main.cpp */
#include stdio.h
extern C {
extern void
c_function (void (*func)(int x));
}
void
ext_function (int x)
{
printf (-- ext_function %d\n, x);
throw test_error;
}
int
main (void)
{
try {
c_function (ext_function);
} catch (...) {
printf (caught test_error\n);
}
return 0;
}
/* c_function.c */
#include stdio.h
void
c_function (void (*func)(int x))
{
printf (-- %s enter\n, __func__);
func (23);
printf (-- %s exit\n, __func__);
}
$ uname -smir
FreeBSD 6.4-RELEASE-p1 i386 GENERIC
$ gcc43 -v
Using built-in specs.
Target: i386-portbld-freebsd6.4
Configured with: ./..//gcc-4.3.2/configure --enable-languages=c,ada
--disable-nls --with-system-zlib --with-libiconv-prefix=/usr/local
--program-suffix=43 --bindir=/usr/local/bin/gcc43
--libdir=/usr/local/lib/gcc-4.3.2 --prefix=/usr/local --mandir=/usr/local/man
--infodir=/usr/local/info/gcc43 --build=i386-portbld-freebsd6.4
Thread model: posix
gcc version 4.3.2 (GCC)
$ c++ -v
Using built-in specs.
Configured with: FreeBSD/i386 system compiler
Thread model: posix
gcc version 3.4.6 [FreeBSD] 20060305
$ gcc43 -o c_function.o -c c_function.c -fPIC -fexceptions -g -W -Werror
-Wall -std=c99 -pedantic-errors -Wno-unused-parameter
$ gcc43 -shared -Wl,-soname,c_function.so -o c_function.so c_function.o -lc
$ c++ -o main.o -c main.cpp -fexceptions -g -W -Werror -Wall -pedantic-errors
-Wno-unused-parameter
$ c++ -o main-dynamic main.o c_function.so
$ c++ -o main-static main.o c_function.o
$ ./main-static
-- c_function enter
-- ext_function 23
caught test_error
LD_LIBRARY_PATH=. ./main-dynamic
-- c_function enter
-- ext_function 23
caught test_error
This example is problematic, however - the C++ compiler is 3.4.6
(I'm not sure how to compile a 4.3.2 gcc with C, Ada and C++ support).
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
