build php with --enable-debug and recreate the backtrace please..

Will do so,
within a week from now I'll post the result.

moving this from 'feedbac' to 'open' as user responded last..  back trace ready yet? :)

Oops... todo got lost, but got it now =)


(gdb) run -X
Starting program: /www/bin/httpd -X
[New Thread 1024 (runnable)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (runnable)]
0x401b4921 in kill () from /lib/libc.so.6

(gdb) bt
#0  0x401b4921 in kill () from /lib/libc.so.6
#1  0x81027f7 in _emalloc ()
#2  0x80966ce in odbc_bindcols ()
#3  0x8097fdf in php_if_odbc_exec ()
#4  0x814c0fa in execute ()
#5  0x8113b34 in zend_execute_scripts ()
#6  0x807fa8f in php_execute_script ()
#7  0x812406c in apache_php_module_main ()
#8  0x807c916 in send_php ()
#9  0x807c94a in send_parsed_php ()
#10 0x8156a89 in ap_invoke_handler ()
#11 0x816b3df in ap_some_auth_required ()
#12 0x816b446 in ap_process_request ()
#13 0x8162366 in ap_child_terminate ()
#14 0x8162521 in ap_child_terminate ()
#15 0x816269c in ap_child_terminate ()
#16 0x8162d0c in ap_child_terminate ()
#17 0x816353c in main ()
#18 0x401aea42 in __libc_start_main () from /lib/libc.so.6

PHP-code is
--- CODESNIPPET::BEGIN ---
<hr>
<?php
$db = odbc_connect('mydb', '', '');
$query = "SELECT * FROM tbl_test";
$result = odbc_do($db, $query);
while(odbc_fetch_row($result)) {
  $cnt_row++;
  print "Got row $cnt_row<br>\n";
  }
?>
<hr>
--- CODESNIPPET::END ---

--- TABLEDEFINITION::BEGIN--
CREATE TABLE [dbo].[tbl_test] (
	[id] [int] IDENTITY (1, 1) NOT NULL ,
	[name] [char] (10) NULL ,
	[text] [ntext] NULL 
)
GO
--- TABLEDEFINITION::END--

This bug should be closed.
If I'm not wrong this problem is due to emalloc tring to allocate to much memory and exiting on failure.
I have sent a patch to fix this problem some time ago.  The patch is applied as of 4.0.7 (or 4.0.6) and the problem does not show up again (at least with Solid).

Basically this is a me-too.

I am running on WinNT4-SP6a with ODBC, MDAC 2.6 and MS-SQL7-SP3. Type casting in the query to text or a varchar does help, but seems a little weird using ODBC functions. Our PHP is version 4.1.0 currently.

Whatever the aforementioned patch is (walter@sys-net.it), it does not seem to be working for me. Sorry, i don't have a trace but would be willing to make one. How do i go about doing that on a precompiled CGI version on WinNT 4?

nTEXT is not a valid ODBC type.  varchar and nvarchar are though, so feel free to use them.  

For more info please see:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odbc/htm/odbcsql_data_types.asp