gdb 5.1 dumped core on me [was: Emacs abort under gdb]

[Francesco Potorti`]

GNU gdb 5.1 configured as i386-linux.

This is the stock GDB in the woody Debian distribution.  

I have files in ftp://fly.cnuce.cnr.it/pub/tmp/gdb-bug/.  They are the
core left by gdb, which is enormous but compressed very well, and the
whole Emacs src dir that I was debugging at the moment.  All in all,
about 30 MB to download, 200 on the disk.

I had run emacs under gdb using this script file:

===File ~/News/emacs.gdb
#! /usr/bin/gdb -x

file /opt/e21/src/emacs
source /opt/e21/src/.gdbinit
r --funcall load-my-desktop


when Emacs crashed.  I have some logs of the session, that I report
below.  The last log is when gdb crashed:

 Last log (gdb crash) 

(gdb) p/x current_buffer-auto_save_file_name
$59 = 0x1827b31c
(gdb) xstring
$60 = (struct Lisp_String *) 0x827b31c
Segmentation fault (core dumped)
-- end of last log ---

In the middle, I had the problem that the x* commands defined in the
.gdbinit file in the emacs src dir did not work:

 Intermediate log (x* commands not working ---

(gdb) p/x current_buffer-size
$46 = 0x2002006d
(gdb) xtype
Lisp_Misc
Argument to arithmetic operation not a number or boolean.
(gdb) p/x current_buffer-size
$48 = 0x2002006d
(gdb) xmisctype
Argument to arithmetic operation not a number or boolean.
--- end of intermidiate log --

This problem disappeared after I issued the xreload command, which too
is defined in the emacs .gdbinit.


--- First log (beginning of session) ---

Fatal error (6).
Program received signal SIGABRT, Aborted.
0x4031a911 in kill () from /lib/libc.so.6
(gdb) bt
#0  0x4031a911 in kill () from /lib/libc.so.6
#1  0x080ceb86 in fatal_error_signal (sig=6) at emacs.c:370
#2  0x4031a848 in sigaction () from /lib/libc.so.6
#3  0x080eef51 in buf_charpos_to_bytepos (b=0x8b867c8, charpos=16230496) at 
marker.c:141
#4  0x08103434 in scan_newline (start=16230496, start_byte=16230496, limit=1, 
limit_byte=1, count=-1, allow_quit=1)
at search.c:761
#5  0x081000e0 in current_column_1 () at indent.c:516
#6  0x080ffd08 in current_column () at indent.c:377
#7  0x08065d50 in redisplay_internal (preserve_echo_area=1) at xdisp.c:8492
#8  0x08066b2a in redisplay_preserve_echo_area (from_where=2) at xdisp.c:9057
#9  0x08056852 in sit_for (sec=0, usec=125000, reading=0, display=1, 
initial_display=1) at dispnew.c:6185
#10 0x0805696d in Fsit_for (seconds=1747435148, milliseconds=405254940, 
nodisp=405254940) at dispnew.c:6234
#11 0x08126377 in Ffuncall (nargs=2, args=0xbfffe434) at eval.c:2720
#12 0x0814d20c in Fbyte_code (bytestr=944247468, vector=1212685872, maxdepth=7) at 
bytecode.c:709
#13 0x0812693b in funcall_lambda (fun=1212686208, nargs=0, arg_vector=0xbfffe5fc) at 
eval.c:2905
#14 0x081264a1 in Ffuncall (nargs=1, args=0xbfffe5f8) at eval.c:2770
#15 0x08125d4e in Fapply (nargs=2, args=0xbfffe5f8) at eval.c:2220
#16 0x081262c2 in Ffuncall (nargs=3, args=0xbfffe5f4) at eval.c:2694
#17 0x0814d20c in Fbyte_code (bytestr=941712480, vector=1210147972, maxdepth=4) at 
bytecode.c:709
#18 0x0812594a in Feval (form=1478583376) at eval.c:2069
#19 0x0812474b in Fcondition_case (args=1479058100) at eval.c:1258
#20 0x0814d6bc in Fbyte_code (bytestr=941712240, vector=1210147820, maxdepth=5) at 
bytecode.c:891
#21 0x0812693b in funcall_lambda (fun=1210147660, nargs=1, arg_vector=0xbfffe978) at 
eval.c:2905
#22 0x081264a1 in Ffuncall (nargs=2, args=0xbfffe974) at eval.c:2770
#23 0x081260af in call1 (fn=405309492, arg1=1210640616) at eval.c:2509
#24 0x080d512b in timer_check (do_it_now=1) at keyboard.c:4090
#25 0x080d415a in readable_events (do_timers_now=1) at keyboard.c:3168
#26 0x080d6dc7 in get_input_pending (addr=0x82737c4, do_timers_now=1) at 
keyboard.c:6058
#27 0x080db001 in detect_input_pending_run_timers (do_display=1) at keyboard.c:9477
#28 0x08151417 in wait_reading_process_input (time_limit=30, microsecs=0, 
read_kbd=268435455, do_display=1)
at process.c:2686
#29 0x08056884 in sit_for (sec=30, usec=0, reading=1, display=1, initial_display=0) at 
dispnew.c:6195
#30 0x080d3116 in read_char (commandflag=1, nmaps=3, maps=0xbfffee04, 
prev_event=405254940,
used_mouse_menu=0xbfffee58) at keyboard.c:2494
#31 0x080d91ad in read_key_sequence (keybuf=0xbfffef64, bufsize=30, prompt=405254940, 
dont_downcase_last=0,
can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:8217
#32 0x080d1784 in command_loop_1 () at keyboard.c:1437
#33 0x08124835 in internal_condition_case (bfun=0x80d1490 command_loop_1, 
handlers=405351332,
hfun=0x80d10c8 cmd_error) at eval.c:1314
#34 0x080d1368 in command_loop_2 () at keyboard.c:1243
#35 0x081243c1 in internal_catch (tag=405312684, func=0x80d1344 command_loop_2, 
arg=405254940) at eval.c:1074
#36 0x080d1312 in command_loop () at keyboard.c:1222
#37 0x080d0e6d in recursive_edit_1 () at keyboard.c:948
#38 

½ö¹©ÓÐÒâÍØÕ¹Öж«Êг¡µÄÆóÒµ¼°É̼Ò

[dongfang681]

µÚ¶þÊ®Æß½ìÖж«£¨µÏ°Ý£©´º¼¾¹ú¼ÊÉÌÆ·½»Ò×»á
Õ¹»áÃû³Æ   µÚ¶þÊ®Æß½ìÖж«£¨µÏ°Ý£©´º¼¾¹ú¼ÊÉÌÆ·½»Ò×»á
Õ¹»áʱ¼ä   2002Äê5ÔÂ5ÈÕÖÁ10ÈÕ
Õ¹»áµØµã   °¢ÁªÇõµÏ°ÝÊÀ½çóÒ×ÖÐÐÄ
±¨Ãû½ØÖ¹   2002Äê2ÔÂ15ÈÕ
չƷ·¶Î§  
¹¤ÒÕÃÀÊõ¡¢Ïä°üЬñ¡¢½¨Öþ²ÄÁÏ¡¢»¯¹¤ÌÕ´É¡¢½ðÒøÊ×ÊΡ¢Á÷ÐÐÊÎÆ·¡¢ÈÕÓÃÆ·¡¢³ø·¿Óþߡ¢µç×Ӽҵ硢·ÄÖ¯ÖÆÆ·¡¢·þ×°ÃæÁÏ¡¢Á¸ÓÍʳƷ¡¢¼Ò¾ß¡¢ÀñÆ·Íæ¾ß¡¢»úµçÎå½ð¡¢Æ¤¸ïÖÆÆ·¡¢µÆ¾ß¡¢°ì¹«ÓÃÆ·¡¢ËÜÁÏÖÆÆ·¡¢¼ÍÄîÆ·¡¢ÌåÓýÓÃÆ·µÈ
Õ¹»á¼ò½é
µÏ°Ý´º½»»áÊÇÖж«ÀúÊ·×îÓƾã¬×îÊÜÍƳçµÄ×ÛºÏÐÔÕ¹»á¡£´ËÕ¹»áÓÉÊÀ½çÕ¹»áÒµµÄÖøÃûÕ¹ÀÀ¹«Ë¾AL 
FAJER³Ð°ì£¬AL FAJER 
¹«Ë¾µÄÇ¿Á¦Ðû´«Íƹãϵͳ½«»áÊÇÕ¹»áÄܹ»Ò»Èç¼ÈÍùµØÊܵ½Öж«¼°Ïà¹ØµØÇøÂò¼Ò¸ß¶È¹Ø×¢µÄ±£Ö¤¡£¶Ô¹ã´óÓÐÒ⿪ÍØÖж«Êг¡µÄÆóÒµÊÇÒ»¸ö×ßÔÚʱ¼äÇ°ÃæµÄ¾ø¼ÑÉÌ»ú£¬½ìʱÊÀ½ç¸÷µØµÄ¿ÍÉ̶¼»á¾Û½¹ÓÚÕâ¸ö·øÉäÖж«Êг¡2000ÒÚÃÀÔ²µÄ½»Ò×ƽ̨¡£
µÏ°Ý¼ò½é
µÏ°ÝËØÓÐÖж«µÄÏã¸ÛÖ®ÃÀÓþ£¬ÊÇ°¢ÁªÇõµÄ½ðÈÚ¾­¼ÃÖÐÐÄ£¬ÒÔÆä×ÔÓÉ¿íËɵľ­¼ÃÕþ²ß¡¢µÃÌì¶ÀºñµÄµØÀíλÖá¢ÍêÉÆÆ뱸µÄ»ù´¡ÉèÊ©£¬Ñ¸ËÙ³ÉΪÖж«µØÇøµÄ½»Í¨ÊàŦºÍ×î´óµÄ»õÎＯɢµØ¡£Í¨¹ýµÏ°Ý£¬»õÎï¿ÉתÏúµ½º£ÍåµØÇø¡¢¶íÂÞ˹¡¢¶«Å·¡¢·ÇÖÞ¡¢µØÖк££¬ÉõÖÁÊÀ½ç¸÷µØ¡£Ä¿Ç°ÎÒ¹ú²úÆ·ÒÔÖÖÀà·±¶à¡¢µµ´ÎÊÊÖС¢¹æ¸ñÆëÈ«¡¢¼Û¸ñºÏÀíÆÄÊÜÇàíù£¬½øÒ»²½¿ª·¢Ç±Á¦¼«´ó¡£
 
2001»Ø¹Ë
2001Äê´º¼¾½»Ò×»áÓÚ2001Äê5ÔÂ1ÈÕÖÁ6ÈÕÔڵϰÝÊÀ½çóÒ×ÖÐÐľÙÐС£¹²À´×Ô20¶à¸ö¹ú¼ÒºÍµØÇø½ü300¼ÒÆóÒµ²ÎÕ¹£¬Õ¹³öÃæ»ý1ƽ·½Ãס£¾Ýͳ¼Æ£¬¹²ÓÐÀ´×ÔÅ·ÃÀ¡¢º£ÍåÁù¹ú¡¢·ÇÖÞ¡¢Ô¶¶«µØÇøµÈ¹ú¼ÒºÍµØÇø1¶àÃûרҵÈËÊ¿µ½»áǢ̸£¬³É½»½ð¶î½ü2ÒÚÃÀÔ²¡£
Ðг̰²Åżò½é
Ϊʹ²ÎÕ¹ÆóÒµÖж«Ö®Ðиü¾ßÒâÒ壬±¾²¿½«½áºÏÆóÒµµÄ²»Í¬ÐèÇó£¬ÍƳöA¡¢BÁ½ÖÖÐг̣º
AÐгÌΪ£º²ÎÕ¹£¨²Î»á£©+Öж«Êг¡¼°ÉÌó¡¢Í¶×Ê»·¾³¿¼²ì£»
BÐгÌΪ£º²ÎÕ¹£¨²Î»á£©+Öж«Êг¡¼°ÉÌó¡¢Í¶×Ê»·¾³¿¼²ì+²Î¼ÓÉÌ󣨱±·Ç£©Ç¢Ì¸»á+
 ±±·Ç£¨°£¼°£©Êг¡¼°ÉÌó¡¢Í¶×Ê»·¾³¿¼²ì£»
´ËÕ¹»áÎÒ˾ÊÜ×éί»áίÍÐÒÔԭʼ¼Û´ú°ì¹úÄÚÏà¹Øרҵ³§É̲ÎÕ¹ÊÂÒË¡£Èç¹ó¹«Ë¾ÓÐÒâ²ÎÕ¹£¬ÇëÌîÍס¶²ÎÕ¹ÉêÇë±í¡·²¢´«ÕæÎÒ˾¡£Í¬Ê±×éÖ¯µÄÕ¹ÀÀ»¹ÓУº
2002.5.5-9  Öж«£¨µÏ°Ý£©¹ú¼ÊÔ˶¯ÐÝÏÐÓÃÆ·²©ÀÀ»á
¶«·½¹ú¼Ê¼¯ÍŹã¸æÕ¹ÀÀÓÐÏÞ¹«Ë¾  
µØ  Ö·£ºÉϺ£±±¾©¶«Â·668ºÅ£¨ÉϺ£¿Æ¼¼¾©³Ç£©¶«Â¥22²ã
µç  »°£º021-5308 ת243 249 224 248   Ö±Ïß:021-53089826
´«  Õæ: 021-5308--250  ×ÉѯÈÈÏß:13162288145
ÁªÏµÈË: ÍõÏÈÉú¡¢ÇñС½ã 
OICQ×ÉѯºÅ£ºÖж«×Éѯ45958196£¨9:00-11:30; 13:30-17:00; 19:00-21:00£©


¶«·½¹ú¼Ê¹ã¸æÕ¹ÀÀÓÐÏÞ¹«Ë¾¼ò½é
  
¶«·½¹ú¼Ê¼¯ÍŹã¸æÕ¹ÀÀÓÐÏÞ¹«Ë¾ÊÇÓɶ«·½¹ú¼Ê¼¯Íųö×Ê2000ÍòÔª×齨µÄ·þÎñóÒ×ÆóÒµ£¬¹éÊôÓÚÉϺ£ÊжÔÍâ¾­¼ÃóÒ×ϵͳ¡£¶«·½¹ú¼Ê¼¯ÍÅÊÇÄ¿Ç°ÔÚÈ«¹ú³ö¿Ú¶îÅÅÃûµÚÒ»µÄ´óÐ͹úÓÐÆóÒµ¡£±¾¹«Ë¾ÊÇÒ»¸ö×ÛºÏÐԵĹã¸æÕ¹ÀÀ¹«Ë¾¡£12ÔÂ9ÈÕ-16ÈÕ,¹«Ë¾³É¹¦µØÓëÊÀ½ç³ÛÃûµÄµÂ¹úººÅµÍþÕ¹ÀÀ¹«Ë¾ºÏ×÷¾Ù°ìÁË2001ÖйúÉϺ£¹ú¼ÊÆû³µÕ¹ÀÀ»á¡£

Öж«ÊÂÎñ²¿½éÉÜ
Ëæ×ÅWTOÀ´ÁÙ£¬±¾¹«Ë¾½«½áºÏ±¾²¿ÔÚÖж«×ÔÉíʵÌåµÄÓÅÊÆ£¬ÌرðÉèÁ¢Öж«ÊÂÎñ²¿£¬Ö¼ÔÚΪÓÐÒâÍØÕ¹Öж«ÖйúÆóÒµÌṩרҵ¡¢ÉîÈëµÄÉÌÎñ·þÎñ£¬Ä¿Ç°ÒÑÓм°¼´½«¿ªÕ¹µÄÏîÄ¿ÓУº
¡ñ  ×éÖ¯²Î¼ÓÖж«(µÏ°Ý)¸÷ÀàÐ͵Äרҵ¹ú¼ÊÕ¹ÀÀ£»
¡ñ ×éÖ¯ÔÚ±±·Ç£¨°£¼°£©µÄÖС¢Ð¡ÐÍÉÌóǢ̸»á£»
¡ñ ×éÖ¯¶ÔÖж«-±±·Ç(°£¼°)µÄÉÌÎñ¿¼²ì£»
¡ñ ЭÖúÆóÒµ´´°ì¾³Íâ´°¿Ú£»
¡ñ ½¨Á¢Öж«ÁªºÏÉÌÎñÖÐÐÄ£¬Ð­ÖúÆóÒµÍêÉƶÔÖж«µØÇøµÄóÒ×Á÷³Ì£»
¡ñ ×éÖ¯Öж«²É¹ºÍŸ°Öйúʵʩ²É¹º£»

___
Bug-gdb mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-gdb

[±¤°í]ÀÌ·± °Ç ¾øÀ»°Ì´Ï´Ù

[test]

Title: Á¦¸ñ ¾øÀ½









 º» E-mailÀº Àü»ê¸Á º¸±ÞÈ®Àå°ú ÀÌ¿ëÃËÁø¿¡ °üÇÑ ¹ý·ü¿¡ ÀÇ°ÅÇÏ¿© ¼ö½ÅÀÚ°¡ [¼ö½Å°ÅºÎ]
Àǻ縦 ȸ½ÅÀ¸·Î ¹àÈùÈÄ¿¡´Â ¶Ç´Ù½Ã º¸³¾¼ö ¾ø½À´Ï´Ù.µû¶ó¼­ Çѹø¸¸ º¸³»µå¸²À» ¾È³»Çص帮¸ç, Ȥ½Ã º»
E-mailÀ» ¹Þ°í ±âºÐÀÌ »óÇÏ¼Ì´Ù¸é ¿ë¼­ÇϽʽÿÀ. ´Ù½Ã´Â º¸³»Áö ¾ÊÀ» °ÍÀÔ´Ï´Ù.¶ÇÇÑ °í°´´ÔÀÇ E-mailÀº °Ô½ÃÆÇÀ» ÅëÇØ ¾Ë°Ô
µÇ¾úÀ¸¸ç °í°´´ÔÀÇ E-mailÀ» Á¦¿ÜÇÑ°³ÀνŻóÁ¤º¸¿¡ ´ëÇؼ­´ÂÀüÇô ¾ËÁö ¸øÇÏ°í ÀÖ»ç¿À´Ï ¾È½ÉÇϽñ⠹ٶø´Ï´Ù.









___
Bug-gdb mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-gdb

½ö¹©ÓÐÒâÍØÕ¹Öж«Êг¡µÄÆóÒµ¼°É̼Ò

[ericpan966]

µÚ¶þÊ®Æß½ìÖж«£¨µÏ°Ý£©´º¼¾¹ú¼ÊÉÌÆ·½»Ò×»á
Õ¹»áÃû³Æ   µÚ¶þÊ®Æß½ìÖж«£¨µÏ°Ý£©´º¼¾¹ú¼ÊÉÌÆ·½»Ò×»á
Õ¹»áʱ¼ä   2002Äê5ÔÂ5ÈÕÖÁ10ÈÕ
Õ¹»áµØµã   °¢ÁªÇõµÏ°ÝÊÀ½çóÒ×ÖÐÐÄ
±¨Ãû½ØÖ¹   2002Äê2ÔÂ15ÈÕ
չƷ·¶Î§  
¹¤ÒÕÃÀÊõ¡¢Ïä°üЬñ¡¢½¨Öþ²ÄÁÏ¡¢»¯¹¤ÌÕ´É¡¢½ðÒøÊ×ÊΡ¢Á÷ÐÐÊÎÆ·¡¢ÈÕÓÃÆ·¡¢³ø·¿Óþߡ¢µç×Ӽҵ硢·ÄÖ¯ÖÆÆ·¡¢·þ×°ÃæÁÏ¡¢Á¸ÓÍʳƷ¡¢¼Ò¾ß¡¢ÀñÆ·Íæ¾ß¡¢»úµçÎå½ð¡¢Æ¤¸ïÖÆÆ·¡¢µÆ¾ß¡¢°ì¹«ÓÃÆ·¡¢ËÜÁÏÖÆÆ·¡¢¼ÍÄîÆ·¡¢ÌåÓýÓÃÆ·µÈ
Õ¹»á¼ò½é
µÏ°Ý´º½»»áÊÇÖж«ÀúÊ·×îÓƾã¬×îÊÜÍƳçµÄ×ÛºÏÐÔÕ¹»á¡£´ËÕ¹»áÓÉÊÀ½çÕ¹»áÒµµÄÖøÃûÕ¹ÀÀ¹«Ë¾AL 
FAJER³Ð°ì£¬AL FAJER 
¹«Ë¾µÄÇ¿Á¦Ðû´«Íƹãϵͳ½«»áÊÇÕ¹»áÄܹ»Ò»Èç¼ÈÍùµØÊܵ½Öж«¼°Ïà¹ØµØÇøÂò¼Ò¸ß¶È¹Ø×¢µÄ±£Ö¤¡£¶Ô¹ã´óÓÐÒ⿪ÍØÖж«Êг¡µÄÆóÒµÊÇÒ»¸ö×ßÔÚʱ¼äÇ°ÃæµÄ¾ø¼ÑÉÌ»ú£¬½ìʱÊÀ½ç¸÷µØµÄ¿ÍÉ̶¼»á¾Û½¹ÓÚÕâ¸ö·øÉäÖж«Êг¡2000ÒÚÃÀÔ²µÄ½»Ò×ƽ̨¡£
µÏ°Ý¼ò½é
µÏ°ÝËØÓÐÖж«µÄÏã¸ÛÖ®ÃÀÓþ£¬ÊÇ°¢ÁªÇõµÄ½ðÈÚ¾­¼ÃÖÐÐÄ£¬ÒÔÆä×ÔÓÉ¿íËɵľ­¼ÃÕþ²ß¡¢µÃÌì¶ÀºñµÄµØÀíλÖá¢ÍêÉÆÆ뱸µÄ»ù´¡ÉèÊ©£¬Ñ¸ËÙ³ÉΪÖж«µØÇøµÄ½»Í¨ÊàŦºÍ×î´óµÄ»õÎＯɢµØ¡£Í¨¹ýµÏ°Ý£¬»õÎï¿ÉתÏúµ½º£ÍåµØÇø¡¢¶íÂÞ˹¡¢¶«Å·¡¢·ÇÖÞ¡¢µØÖк££¬ÉõÖÁÊÀ½ç¸÷µØ¡£Ä¿Ç°ÎÒ¹ú²úÆ·ÒÔÖÖÀà·±¶à¡¢µµ´ÎÊÊÖС¢¹æ¸ñÆëÈ«¡¢¼Û¸ñºÏÀíÆÄÊÜÇàíù£¬½øÒ»²½¿ª·¢Ç±Á¦¼«´ó¡£
 
2001»Ø¹Ë
2001Äê´º¼¾½»Ò×»áÓÚ2001Äê5ÔÂ1ÈÕÖÁ6ÈÕÔڵϰÝÊÀ½çóÒ×ÖÐÐľÙÐС£¹²À´×Ô20¶à¸ö¹ú¼ÒºÍµØÇø½ü300¼ÒÆóÒµ²ÎÕ¹£¬Õ¹³öÃæ»ý1ƽ·½Ãס£¾Ýͳ¼Æ£¬¹²ÓÐÀ´×ÔÅ·ÃÀ¡¢º£ÍåÁù¹ú¡¢·ÇÖÞ¡¢Ô¶¶«µØÇøµÈ¹ú¼ÒºÍµØÇø1¶àÃûרҵÈËÊ¿µ½»áǢ̸£¬³É½»½ð¶î½ü2ÒÚÃÀÔ²¡£
Ðг̰²Åżò½é
Ϊʹ²ÎÕ¹ÆóÒµÖж«Ö®Ðиü¾ßÒâÒ壬±¾²¿½«½áºÏÆóÒµµÄ²»Í¬ÐèÇó£¬ÍƳöA¡¢BÁ½ÖÖÐг̣º
AÐгÌΪ£º²ÎÕ¹£¨²Î»á£©+Öж«Êг¡¼°ÉÌó¡¢Í¶×Ê»·¾³¿¼²ì£»
BÐгÌΪ£º²ÎÕ¹£¨²Î»á£©+Öж«Êг¡¼°ÉÌó¡¢Í¶×Ê»·¾³¿¼²ì+²Î¼ÓÉÌ󣨱±·Ç£©Ç¢Ì¸»á+
 ±±·Ç£¨°£¼°£©Êг¡¼°ÉÌó¡¢Í¶×Ê»·¾³¿¼²ì£»
´ËÕ¹»áÎÒ˾ÊÜ×éί»áίÍÐÒÔԭʼ¼Û´ú°ì¹úÄÚÏà¹Øרҵ³§É̲ÎÕ¹ÊÂÒË¡£Èç¹ó¹«Ë¾ÓÐÒâ²ÎÕ¹£¬ÇëÌîÍס¶²ÎÕ¹ÉêÇë±í¡·²¢´«ÕæÎÒ˾¡£Í¬Ê±×éÖ¯µÄÕ¹ÀÀ»¹ÓУº
2002.5.5-9  Öж«£¨µÏ°Ý£©¹ú¼ÊÔ˶¯ÐÝÏÐÓÃÆ·²©ÀÀ»á
¶«·½¹ú¼Ê¼¯ÍŹã¸æÕ¹ÀÀÓÐÏÞ¹«Ë¾  
µØ  Ö·£ºÉϺ£±±¾©¶«Â·668ºÅ£¨ÉϺ£¿Æ¼¼¾©³Ç£©¶«Â¥22²ã
µç  »°£º021-5308 ת243 249 224 248   Ö±Ïß:021-53089826
´«  Õæ: 021-5308--250  ×ÉѯÈÈÏß:13162288145
ÁªÏµÈË: ÍõÏÈÉú¡¢ÇñС½ã 
OICQ×ÉѯºÅ£ºÖж«×Éѯ45958196£¨9:00-11:30; 13:30-17:00; 19:00-21:00£©


¶«·½¹ú¼Ê¹ã¸æÕ¹ÀÀÓÐÏÞ¹«Ë¾¼ò½é
  
¶«·½¹ú¼Ê¼¯ÍŹã¸æÕ¹ÀÀÓÐÏÞ¹«Ë¾ÊÇÓɶ«·½¹ú¼Ê¼¯Íųö×Ê2000ÍòÔª×齨µÄ·þÎñóÒ×ÆóÒµ£¬¹éÊôÓÚÉϺ£ÊжÔÍâ¾­¼ÃóÒ×ϵͳ¡£¶«·½¹ú¼Ê¼¯ÍÅÊÇÄ¿Ç°ÔÚÈ«¹ú³ö¿Ú¶îÅÅÃûµÚÒ»µÄ´óÐ͹úÓÐÆóÒµ¡£±¾¹«Ë¾ÊÇÒ»¸ö×ÛºÏÐԵĹã¸æÕ¹ÀÀ¹«Ë¾¡£12ÔÂ9ÈÕ-16ÈÕ,¹«Ë¾³É¹¦µØÓëÊÀ½ç³ÛÃûµÄµÂ¹úººÅµÍþÕ¹ÀÀ¹«Ë¾ºÏ×÷¾Ù°ìÁË2001ÖйúÉϺ£¹ú¼ÊÆû³µÕ¹ÀÀ»á¡£

Öж«ÊÂÎñ²¿½éÉÜ
Ëæ×ÅWTOÀ´ÁÙ£¬±¾¹«Ë¾½«½áºÏ±¾²¿ÔÚÖж«×ÔÉíʵÌåµÄÓÅÊÆ£¬ÌرðÉèÁ¢Öж«ÊÂÎñ²¿£¬Ö¼ÔÚΪÓÐÒâÍØÕ¹Öж«ÖйúÆóÒµÌṩרҵ¡¢ÉîÈëµÄÉÌÎñ·þÎñ£¬Ä¿Ç°ÒÑÓм°¼´½«¿ªÕ¹µÄÏîÄ¿ÓУº
¡ñ  ×éÖ¯²Î¼ÓÖж«(µÏ°Ý)¸÷ÀàÐ͵Äרҵ¹ú¼ÊÕ¹ÀÀ£»
¡ñ ×éÖ¯ÔÚ±±·Ç£¨°£¼°£©µÄÖС¢Ð¡ÐÍÉÌóǢ̸»á£»
¡ñ ×éÖ¯¶ÔÖж«-±±·Ç(°£¼°)µÄÉÌÎñ¿¼²ì£»
¡ñ ЭÖúÆóÒµ´´°ì¾³Íâ´°¿Ú£»
¡ñ ½¨Á¢Öж«ÁªºÏÉÌÎñÖÐÐÄ£¬Ð­ÖúÆóÒµÍêÉƶÔÖж«µØÇøµÄóÒ×Á÷³Ì£»
¡ñ ×éÖ¯Öж«²É¹ºÍŸ°Öйúʵʩ²É¹º£»

___
Bug-gdb mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-gdb

[] bug-gdb ?

¼¼»óÀÇ ¹ÝÀº ¿©ÀÚ, ¼¼»óÀÇ ¹ÝÀº ³²ÀÚ.

±× Àý¹ÝÀÇ ±ÕÇü¿¡¼­ ÇÑÆò»ýÀ» ÇÔ²² ÇÒ ³²ÀÚ¸¦ ã°í ¿©ÀÚ¸¦ ã´Â ³¡¾ø´Â µµÀü°ú ÀÀÀü.
ÀÌ»óÇâÀÇ ³²ÀÚ¿Í ¿©ÀÚ¸¦ ¸¸³ª °¡Á¤À̶õ ¼º¿¡¼­ "ȯ»óÀÇ ºÒ²ÉÃàÁ¦"¸¦ ²Þ²Ù´Â °áÈ¥.

±×·¯³ª "Äð¸®ÁöÈ¿°ú"¶ó´Â Çö½ÇÀÇ º®ÀÌ ÀÖ´Ù°í ÇÕ´Ï´Ù.
4³âÀ» ÁÖ±â·Î ÆÄÆ®³Ê¸¦ ¹Ù²Ù¸é ºÎºÎ°ü°èÀÇ È½¼ö°¡ ÁÙÁö ¾Ê°í ºÎºÎ°ü°èµµ ±ÇÅ·ÓÁö
¾ÊÀ» °ÍÀ̶ó´Â "4³â Áֱ⼳"À» ¼ºÀÇÇÐÀÚ Äð¸®Áö´Â ¶°µé°í ÀÖ½À´Ï´Ù.

»õ·Î¿î À̼º¿¡ ´ëÇÑ È£±â½É°ú ¼³·¹ÀÓÀº ´©±¸¿¡°Ô³ª ÀÖ½À´Ï´Ù.
ÀÚ½ÅÀÇ °ü¸®¼ÒȦ·Î ÀÎÇØ ¸Á°¡Áö°í ¹ö·ÁÁö´Â °ÍÀÌ ´ëºÎºÐÀε¥ ±× ´©±¸µµ ÀÚ½ÅÀÇ
½Ç¼ö¸¦ ÀÎÁ¤ÇÏ·Á µéÁö ¾Ê°í »õ °Í¿¡ ´ëÇÑ ²÷ÀÓ¾ø´Â °ü½É¸¸ ÀÖÀ» »ÓÀÔ´Ï´Ù.

³²ÀÚÀÇ ¹«¾ùÀÌ ¿©ÀÚ¸¦ ¹ÛÀ¸·Î µ¹°ÔÇÏ°í 
¿©ÀÚÀÇ ¹«¾ùÀÌ ³²ÀÚÀÇ ´«À» ÈÒÈÒ µ¹¾Æ°¡°Ô ÇÏ´ÂÁö ¾Ë ¼ö¸¸ ÀÖ´Ù¸é 
Äð¸®ÁöÈ¿°ú´Â ÅëÇÏÁö ¾ÊÀ» °ÍÀ̶ó È®½ÅÇÕ´Ï´Ù.

´ÔÀ» ¸¸³ª À̾߱â ÇÏ°í ½Í½À´Ï´Ù.
Äð¸®ÁöÈ¿°ú¸¦ ¾î¶»°Ô ¹°¸®ÃÄ¾ß ÇÏ´ÂÁö ÇÔ²² À̾߱â ÇÏ°í ½Í½À´Ï´Ù.
www.EVErang.com Àº ¿©ÀÚ¿Í ³²ÀÚ°¡ ÇÔ²² ÇÏ´Â °÷ÀÔ´Ï´Ù.

ÀÎÅÍ³Ý °Ô½ÃÆÇ¿¡¼­ ´ÔÀÇ À̸ÞÀÏÁÖ¼Ò¸¦ ¾Ë°Ô µÇ¾ú°í ±âŸ ±× ¾î¶² Á¤º¸µµ
ÀúÈñ´Â °®°í ÀÖÁö ¾Ê½À´Ï´Ù.
ºÒÄèÇϼ̴ٸé Á˼ÛÇÕ´Ï´Ù.
¾Æ·¡ÀÇ ¼ö½Å°ÅºÎ¸¦ Ŭ¸¯ÇÏ½Ã¸é ¾ÕÀ¸·Î ¸ÞÀÏÀ» º¸³»Áö ¾Ê°Ú½À´Ï´Ù.


¼ö½Å°ÅºÎ
 



 
  



 
  



 
  



 
  



 
  
  

±â¾÷Á¤º¸»çÀÌÆ®ÀÇ ½Å³â¸ÂÀÌ °æÇ°À̺¥Æ®~~!!

[Korea EIR]

Title: event_main




	
		
			
		
			
		
			
		
			
		
			
		
			
		
			
	
	
		
			
		
 
		
			
	
	
		
			
	
	
		
			
		
			
	
	
		
			
	
	
		
 
		
			
	
	
		
 
		
			
	
	
		
			
	
	
		
			
		
			
	
	
		
			
		
 
		
			
	
	
		
			
	


  


  
  




___
Bug-gdb mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-gdb

GDB 5.1 problem printing member variables

[Gary Kroening]

Hi,
I originally sent this to Jim, but then noticed in the gdb README info
that I should send it to bug-gdb -- sorry, Jim!

Per the explanation in the README file, here's the gdb banner:

metis:prom_efi ~/tmp/gnu/gdb-5.1/build/gdb/gdb \
~/workarea/osprey1.0/targia32_ia64/medusa/medusa 
GNU gdb 5.1
Copyright 2001 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB.  Type show warranty for details.
This GDB was configured as i686-pc-linux-gnu...
(gdb) 


As described below, I used 'configure' with no options, and the problem seems
common to at least IA32 (i*86), IA64, and MIPS.

 Original Message 
Subject: GDB 5.1 problem printing member variables
Date: Fri, 18 Jan 2002 13:33:56 -0600 (CST)
From: Gary Kroening [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED], [EMAIL PROTECTED]

Hi Jim,
My name is Gary Kroening ([EMAIL PROTECTED] phone 651-683-5277). I work at
SGI, currently doing simulation of IA64 machines. I hope it's
appropriate to contact you on this topic, but please let me know if
I should take a different approach. I found your name in the file
gnu-v3-abi.c in the GDB 5.1 source.

I'm wondering if you know how to fix or work around a problem that
seems to be an incompatibility between gcc/g++ and gdb. I'll try not
to be too long-winded here, in case you've already answered this for
someone else. Please ask if you need more info.


Summary:

I can't print member variables of objects generated by g++ v3.x,
using the print command in gdb. I can print local variables,
and print the this pointer, but gdb can't seem to dereference the
this pointer. I get:

(gdb) p this
$1 = (IA64HwCpu * const) 0x10fbe5b8
(gdb) p *this
Value can't be converted to integer.
(gdb) p fault  # fault is a data member of IA64HwCpu class.
Value can't be converted to integer.


Note that if I debug an executable generated by g++ 2.x (2.96 in this
case), things work OK with both an old gdb 4.17 and gdb 5.1.


More details:
-

Background: I'm trying to get compatible versions of gcc/g++ and
gdb running on the following platforms: IA32, IA64, and MIPS. I've
been able to get gcc 3.0.3 to compile my simulator on IA32 and MIPS;
I have trouble getting gcc 3.0.3 itself to build on IA64, so I'm using
gcc 3.0 there. The trouble seems to be for all versions of gcc 3.x.

When I first tried to debug programs with the old version of gdb we
had around (4.17), it died trying to load and debug executables from
the new gcc 3.x compilers. So I downloaded gdb 5.1. I configured and
build it like the README file said:

cd $GDB_SRC
mkdir build
cd build
$GDB_SRC/configure
gmake   === tried make and gmake, gmake seems better


I don't know anything about gdb design, but I've done some
investigating on the problem. The message is coming from values.c,
in the function unpack_long().

Here's what happens when I type print *this:

If I'm debugging a g++ 2.x executable, unpack_long() is called twice,
with the following TYPE_CODEs:

TYPE_CODE_PTR
TYPE_CODE_PTR

(It actually gets called a few more times after this.) If I'm debugging
a g++ 3.x executable, I see:

TYPE_CODE_PTR
TYPE_CODE_STRUCT

unpack_long() doesn't have a case to handle TYPE_CODE_STRUCT, so it
bails out. 


I tried to learn a little more about what's happening on the second
call to unpack_long(). For both 2.x and 3.x, unpack_long() is called
by value_as_pointer() (also in values.c). When debugging the 2.x program, 
value_as_pointer() is called by gnu-v2-abi.c::gnuv2_value_rtti_type(),
and for the 3.x program, gnu-v3-abi.c::gnuv3_value_rtti_type().




From there, I tried a bunch of things such as hacking unpack_long(),
etc., but I don't know what I'm doing. Also, my brain started to fail,
since I was running gdb on gdb on my simulator, which was simulating
Linux!


I hope I've given you enough info to go on, but please let me know if
I should send more info, or contact someone else. This is the first
time I've tried to resolve a gdb problem.

Thanks.
Gary

___
Bug-gdb mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-gdb

Gdb breakpoint bug with gcc3 on RedHat7.2

[Allen King]

/*:
There seems to be a bug in gdb which causes it to not stop at certain
breakpoints. It occurs with C++ sources compiled with gcc3-3.02,
but not when
gcc2-2.96 is used. All gdb versions I tried (ver 5.0rh-15 and
5.1.0.1) had
the same problem.
I'm suspecting there may be newer versions around which have had this
(rather
basic) bug fixed, or perhaps I'm doing something wrong (..naaw).
If you can, I could use workaround/upgrade suggestions quick, as I
live in gdb
and have found progress come to a grinding halt.
The program I first encountered this in was rather large (64K lines),
but I
isolated the behavior down to the following 16-line program:
//
(line 0)
#include stdio.h>
class foo {
public:
 foo (int* parent = 0, const char *name = 0);
};
int main (int argc, char **argv) {
 foo *myObject = new foo (0, "interface");
// A (line 9)
 return myObject!=0; // reference it
}
foo::foo (int *parent, const char *name) {
 printf("Why didn't the gdb breakpoint stop here?\n");
//B (line 14)
}
/* vv
Info (per www.gnu.org/manual/gdb-4.17/html_chapter/gdb_18.html) is:
 gcc:
Both gcc3-3.0.1-3.i386.rpm (and friends) (which I did most work on)
and
gcc3-3.0.2-1hn.i586.rpm (and friends) (just installed) seem to have
the same
problem. gcc2-2.96 works fine -- stops at both breakpoints.
 Gdb:
5.0rh-15 (from 7.2 CD) and 5.1.0.1 (made with gcc3) have the same problem.
 OS:
RedHat.7.2, vmlinuz-2.4.7.
 CPU:
AMD-K6(tm) 3D processor, 400MHz
 Build and Recreate Problem:
Gdb fails to stop at the breakpoint on line 14 of the above program.
However
it is clear that line 14, a printf, does get executed -- My console
log:
[me@gibson src]$ g++ --version
3.0.2
[me@gibson src]$ g++ -g main.cpp -o main
[me@gibson src]$ gdb ./main
GNU gdb Red Hat Linux 7.x (5.0rh-15) (MI_OUT)
Copyright 2001 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty"
for details.
This GDB was configured as "i386-redhat-linux"...
(gdb) b 9
Breakpoint 1 at 0x804874d: file main.cpp, line 9.
(gdb) b 14
Breakpoint 2 at 0x80487de: file main.cpp, line 14.
(gdb) r
Starting program: /home/me/main
Breakpoint 1, main (argc=1, argv=0xb1d4) at main.cpp:9
9 foo *myObject
= new foo (0, "interface");
// A
(gdb) inf b
Num Type
Disp Enb Address What
1 breakpoint keep y
0x0804874d in main at main.cpp:9
 breakpoint already hit 1
time
2 breakpoint keep y
0x080487de in foo::foo(int*, char const*)

at main.cpp:14
(gdb) l 14
14 printf("Why didn't the gdb breakpoint stop here?\n");
//B
(gdb) c
Continuing.
Why didn't the gdb breakpoint stop here?
Program exited with code 01.

 Aside
In upgrading RedHat7.2 to gcc3, I hit a knarrly problem, which I solved.
However it involved much more hackery than I would have expected, so
I'm
just bringing it up as a double check: I had loaded/installed rpm's
as follows:
 gcc3-3.0.1-3.i386.rpm
 gcc3-c++-3.0.1-3.i386.rpm
 libgcc-3.0.1-3.i386.rpm
 libstdc++3-3.0.1-3.i386.rpm
 libstdc++3-devel-3.0.1-3.i386.rpm
and compiles gave the error: "cannot find deque.h". File libstdc++-v3/README
had the cryptic comment: "(A configure script may link files from another
directory into one of these.)
The hack I did was to add about 200 symbolic links:
 in /usr/include/bits, added symlinks to all files
(not directories)
in the following directories:
 /usr/include/g++-v3
 /usr/include/g++-v3/bits
 /usr/include/g++-v3/i386-redhat-linux/bits
 and in /usr/include, added symlinks to all files
in directory:
 /usr/include/g++-v3/backward
How I determined this was by a painstaking series of compillations of
a C++
program which referenced deque.h, isolating the missing include files
and
linking where the above rpms' placed them.
Compillations after this were errorless.

--
 Allen
 781-248-6897 cell
 781-449-3359 home