>	mysqld-nt.exe!Item_field::fix_outer_field()  + 0x7f bytes	C++
 	mysqld-nt.exe!Item_field::fix_fields()  + 0x148 bytes	C++
 	mysqld-nt.exe!join_read_always_key_or_null()  + 0x682 bytes	C++
 	mysqld-nt.exe!setup_order()  + 0x37 bytes	C++
 	mysqld-nt.exe!setup_without_group()  + 0x87 bytes	C++
 	mysqld-nt.exe!JOIN::prepare()  + 0x1c1 bytes	C++
 	mysqld-nt.exe!mysql_select()  + 0xc6 bytes	C++
 	mysqld-nt.exe!st_select_lex_unit::exec()  + 0x551 bytes	C++
 	mysqld-nt.exe!mysql_derived_filling()  + 0x46 bytes	C++
 	mysqld-nt.exe!mysql_handle_derived()  + 0x4d bytes	C++
 	mysqld-nt.exe!open_and_lock_tables()  + 0xb4 bytes	C++
 	mysqld-nt.exe!mysql_execute_command()  + 0x2e2 bytes	C++
 	
 	
 	
 	Version: '5.0.38-debug'  socket: '/tmp/mysql.sock'  port: 3306  yes
mysqld got signal 11;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help diagnose
the problem, but since we have already crashed, something is definitely wrong
and this may fail.

key_buffer_size=8388572
read_buffer_size=131072
max_used_connections=1
max_connections=100
threads_connected=1
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 225788 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x8c05170
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
Cannot determine thread, fp=0xbe5fe738, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x80de94b handle_segfault + 417
0x83d60cd __pthread_sighandler + 173
0x8056515 _ZN10Item_field15fix_outer_fieldEP3THDPP5FieldPP4Item + 99
0x8056db3 _ZN10Item_field10fix_fieldsEP3THDPP4Item + 543
0x8149895 _Z18find_order_in_listP3THDPP4ItemP13st_table_listP8st_orderR4ListIS1_ESA_b + 633
0x814997b _Z11setup_orderP3THDPP4ItemP13st_table_listR4ListIS1_ES8_P8st_order + 83
0x812eabe _ZN4JOIN7prepareEPPP4ItemP13st_table_listjS1_jP8st_orderS7_S1_S7_P13st_select_lexP18st_select_lex_unit + 850
0x81334f3 _Z12mysql_selectP3THDPPP4ItemP13st_table_listjR4ListIS1_ES2_jP8st_orderSB_S2_SB_yP13select_resultP18st_select_lex_unitP13st_sel + 277
0x82043b7 _ZN18st_select_lex_unit4execEv + 2595
0x8205037 _Z21mysql_derived_fillingP3THDP6st_lexP13st_table_list + 85
0x8204c12 _Z20mysql_handle_derivedP6st_lexPFbP3THDS0_P13st_table_listE + 82
0x81220ab _Z20open_and_lock_tablesP3THDP13st_table_list + 257
0x80f5e04 _Z21mysql_execute_commandP3THD + 1176
0x80fe2fe _Z11mysql_parseP3THDPcj + 380
0x80f4262 _Z16dispatch_command19enum_server_commandP3THDPcj + 1940
0x80f3ac2 _Z10do_commandP3THD + 538
0x80f2c57 handle_one_connection + 991
0x83d0fa1 pthread_start_thread + 225
0x842be3a __clone + 106
New value of fp=(nil) failed sanity check, terminating stack trace!
Please read http://dev.mysql.com/doc/mysql/en/using-stack-trace.html and follow instructions on how to resolve the stack trace. Resolved
stack trace is much more helpful in diagnosing the problem, so please do 
resolve it
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x8c199b0 = SELECT User FROM
(
        SELECT * FROM mysql.user
UNION
        SELECT * FROM mysql.user
ORDER BY unknown_column
) AS test
thd->thread_id=1
The manual page at http://www.mysql.com/doc/en/Crashing.html contains
information that should help you find out what is causing the crash.

Number of processes running now: 1