Re: X86_64 Segmentation fault - patch (or Re: AMD64 Segmentation fault)

Hi Ilan,

Ilan Aelion wrote:

> Hi David, all,
> 
> I had the same problem more or less on a x86_64 (Intel Xeon). I run
> configure with or without --with-cflags=-m64 flag, then compile (and
> receive a few ominous warnings) and finally try to run the bearer box,
> which crashes immediately.
> 
> The compiler issues warnings that seem word width related for
> * gw/bb_boxc.c
> * gw/smsc/smsc_at.c
> * gwlib/octstr.c
> 
> Here's a tiny patch for octstr.c that eliminates the SEGV (as well as the
> compiler warnings for this file) on x86_64:
> 
> Index: octstr.c
> ===================================================================
> RCS file: /home/cvs/gateway/gwlib/octstr.c,v
> retrieving revision 1.163
> diff -u -r1.163 octstr.c
> --- octstr.c    11 Aug 2004 16:41:29 -0000      1.163
> +++ octstr.c    31 Dec 2004 12:02:37 -0000
> @@ -79,7 +79,7 @@
>   * Unfortunately some platforms base va_list an an array type
>   * which makes passing of the &args a bit tricky
>   */
> -#if defined(__linux__) && (defined(__powerpc__) || defined(__s390__))
> +#if defined(__linux__) && (defined(__powerpc__) || defined(__s390__) ||
> defined(__x86_64))
>  #define VARGS(x)   (x)
>  #define VALPARM(y) va_list y
>  #define VALST(z)   (z)
> 

commited to cvs. Thanks!

> If you want to try the same thing for your platform, you'll need to add a
> test
> using  the correct macro for AMD64 rather than x86_64. If you're not sure
> what it is, check what predefined macros you have. To get a list of
> predefined macros, try
> 
> $ echo blah | cpp -dM
> 
> 
> This still doesn't fix the warnings for the other two files, perhaps
> kannel gurus might be able to fix those as well? Here is the compiler
> output:
> 
> gw/bb_boxc.c: In function `run_smsbox':
> gw/bb_boxc.c:584: warning: cast from pointer to integer of different size
> gw/bb_boxc.c: In function `run_wapbox':
> gw/bb_boxc.c:677: warning: cast from pointer to integer of different size
> gw/bb_boxc.c: In function `wait_for_connections':
> gw/bb_boxc.c:918: warning: cast to pointer from integer of different size
> gw/bb_boxc.c: In function `smsboxc_run':
> gw/bb_boxc.c:937: warning: cast from pointer to integer of different size
> gw/bb_boxc.c: In function `wapboxc_run':
> gw/bb_boxc.c:995: warning: cast from pointer to integer of different size
> 
> - figures, since sizeof(void *) != sizeof(int) on a 64 bit OS. But why are
> the file descriptors being passed as void pointers in the first place?
> 

patch will follow on ML...

> 
> gw/smsc/smsc_at.c: In function `at2_read_buffer':
> gw/smsc/smsc_at.c:192: warning: comparison is always false due to limited
> range of data type
> gw/smsc/smsc_at.c:193: warning: overflow in implicit constant conversion
> 
> - SSIZE_MAX is LONG_MAX rather than INT_MAX on a 64 bit OS. But since an
> int can't be greater than INT_MAX, the condition would never be true
> anyway.

fixed in cvs.

> 
> cheers,
> - Ilan
> 
>>
>> Date: Sat, 4 Dec 2004 16:38:06 +0000
>> From: David Blackburn <[email protected]>
>> Subject: AMD64 Segmentation fault
>> To: [email protected]
>> Message-ID: <[email protected]>
>> Content-Type: text/plain; charset=US-ASCII
>> 
>> Hi
>> 
>> Is anyone running kannel on a AMD64 processor ? I have recompiled
>> kannel using the same parameters as on my AMD XP and I keep getting
>> seg faults when I try and start the bearerbox.  I have tried with a
>> cut down config ( see below ) and still gets no further that below.
>> 
>> Any help would be greatly apreciated.
>> 
>> Regards
>> Dave
>> 
>> 
>> # ./bearerbox
>> 2004-12-04 16:33:26 [12947] [0] INFO: Debug_lvl = -1, log_file =
>> <none>, log_lvl = 0
>> 2004-12-04 16:33:26 [12947] [0] WARNING: DLR: using default 'internal'
>> for storage type.
>> 2004-12-04 16:33:26 [12947] [0] INFO: DLR using storage type: internal
>> Segmentation fault
>> 
>> kannel.conf
>> group = core
>> admin-port = 13000
>> admin-password = bar
>> 
>> Build Parametters.
>> ./configure --prefix=/test/ktest --disable-ssl
>> --with-mysql-dir=/usr/lib64/mysql/
>> 
>> 
>> 
>>

-- 
Thanks,
Alex