View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0002006XdebugStep Debuggingpublic2021-08-07 17:082022-04-04 11:32
ReporterZobo Assigned Toderick  
PrioritynormalSeveritycrashReproducibilityalways
Status closedResolutionfixed 
Product Version3.0.4 
Fixed in Version3.1.4 
Summary0002006: Removing second call breakpoint with same function name
Description

I added two call breakpoints with same name. Removing both caused a segfault. Could reproduce on 7.2.24/2.6.0 and 8.0/3.0.4.

The function does not need to exist, only the name must be the same on both calls to breakpoint_set.

Steps To Reproduce

dbgpClient.exe -x
Xdebug Simple DBGp client (0.4.2)
Copyright 2019-2020 by Derick Rethans
In dumb client mode

Waiting for debug server to connect on port 9003.
Connect from [::1]:54751
<?xml version="1.0" encoding="iso-8859-1"?>
<init xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" fileuri="file:///C:/local_disk/zobo/Projects/vscode-php-debug/vscode-php-debug/testproject/hit.php" language="PHP" xdebug:language_version="8.0.4RC1" protocol_version="1.0" appid="10004"><engine version="3.0.4"><![CDATA[Xdebug]]></engine><author><![CDATA[Derick Rethans]]></author><url><![CDATA[https://xdebug.org]]></url><copyright><![CDATA[Copyright (c) 2002-2021 by Derick Rethans]]></copyright></init>
DBGp/1.0: Xdebug 3.0.4 — For PHP 8.0.4RC1
Debugging file:///C:/local_disk/zobo/Projects/vscode-php-debug/vscode-php-debug/testproject/hit.php (ID: 10004/)
(cmd) breakpoint_set -t call -m a
<?xml version="1.0" encoding="iso-8859-1"?>
<response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="breakpoint_set" transaction_id="1" id="100040001"></response>
1 | breakpoint_set
1 | Breakpoint set with ID 100040001

(cmd) breakpoint_set -t call -m a
<?xml version="1.0" encoding="iso-8859-1"?>
<response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="breakpoint_set" transaction_id="2" id="100040002"></response>
2 | breakpoint_set
2 | Breakpoint set with ID 100040002

(cmd) breakpoint_remove -d 100040001
<?xml version="1.0" encoding="iso-8859-1"?>
<response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="breakpoint_remove" transaction_id="3"><breakpoint type="call" function="a" state="enabled" hit_count="0" hit_value="0" id="100040002"></breakpoint></response>
3 | breakpoint_remove
3 | (0) 100040002 call: a

(cmd) breakpoint_remove -d 100040002
Error while handling connection: Error reading length: read tcp [::1]:9003->[::1]:54751: wsarecv: An existing connection was forcibly closed by the remote host.
Disconnect

Additional Information

This GDB is from 7.2.24/2.6.0 and without debug symbols, but just for an idea where to start...

(gdb) r -dxdebug.remote_enable=1 -dxdebug.remote_port=9003 test3.php
Starting program: /usr/bin/php -dxdebug.remote_enable=1 -dxdebug.remote_port=9003 test3.php
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
breakpoint_brk_info_add (xml=xml@entry=0x8a89970, brk_info=brk_info@entry=0x0) at ./build-7.2/xdebug_handler_dbgp.c:507
507 ./build-7.2/xdebug_handler_dbgp.c: No such file or directory.
(gdb) bt
#0 breakpoint_brk_info_add (xml=xml@entry=0x8a89970, brk_info=brk_info@entry=0x0) at ./build-7.2/xdebug_handler_dbgp.c:507
#1 0x00007ffffa34e2fe in breakpoint_do_action (retval=0x7ffffffea740, context=0x7ffffa5703c8 <xdebug_globals+840>, args=0x8a8d760, action=2)
at ./build-7.2/xdebug_handler_dbgp.c:711
0000002 0x00007ffffa34bacc in xdebug_dbgp_parse_option (flags=0, retval=<optimized out>, line=0x8a8da00 "breakpoint_remove -i 4 -d 2710002",
context=0x7ffffa5703c8 <xdebug_globals+840>) at ./build-7.2/xdebug_handler_dbgp.c:2119
0000003 xdebug_dbgp_cmdloop (context=context@entry=0x7ffffa5703c8 <xdebug_globals+840>, bail=bail@entry=1) at ./build-7.2/xdebug_handler_dbgp.c:2163
0000004 0x00007ffffa34f377 in xdebug_dbgp_init (context=0x7ffffa5703c8 <xdebug_globals+840>, mode=<optimized out>)
at ./build-7.2/xdebug_handler_dbgp.c:2268
0000005 0x00007ffffa353a38 in xdebug_init_debugger () at ./build-7.2/xdebug_stack.c:602
0000006 0x00007ffffa33f851 in xdebug_execute_ex (execute_data=0x7ffffa81c030) at ./build-7.2/xdebug.c:1787
0000007 0x00000000083550e7 in zend_execute ()
0000008 0x00000000082a3882 in zend_execute_scripts ()
0000009 0x000000000823f2d0 in php_execute_script ()
0000010 0x00000000083574fc in ?? ()
0000011 0x00000000080ec65b in ?? ()
0000012 0x00007ffffd411bf7 in __libc_start_main (main=0x80ec240, argc=4, argv=0x7ffffffee218, init=<optimized out>, fini=<optimized out>,
rtld_fini=<optimized out>, stack_end=0x7ffffffee208) at ../csu/libc-start.c:310
0000013 0x00000000080ec7fa in _start ()

TagsNo tags attached.
Operating System
PHP Version8.0.0-8.0.4

Activities

derick

2022-03-29 16:30

administrator   ~0006262

Hi,

sorry, I missed this showing up in the queue! I can reproduce this, and know what the problem is. There are two ways of fixing it:

  1. Don't allow two breakpoints for the same function/method call
  2. Do reference counting of the internal structures

The spec says:

It is up to the engine on how to handle multiple "similar" breakpoints, such as a double breakpoint on a specific file/line combination - even if other parameters such as hit_value/hit_condition are different.

The first option means I will have to check and return error "200" although I suppose this technically could be considered a BC break. The second one means I will have to make things more complicated and keep track of some internal structures.

I am currently leaning towards option 1, but would love to hear your opinion too.

cheers,
Derick

derick

2022-03-30 17:45

administrator   ~0006263

https://github.com/xdebug/xdebug/pull/830

derick

2022-03-31 08:56

administrator   ~0006264

Fixed for 3.1.4.

Issue History

Date Modified Username Field Change
2021-08-07 17:08 Zobo New Issue
2022-03-29 16:30 derick Assigned To => derick
2022-03-29 16:30 derick Status new => confirmed
2022-03-29 16:30 derick Note Added: 0006262
2022-03-29 16:30 derick Status confirmed => feedback
2022-03-30 17:45 derick Note Added: 0006263
2022-03-31 08:56 derick Status feedback => closed
2022-03-31 08:56 derick Resolution open => fixed
2022-03-31 08:56 derick Fixed in Version => 3.1dev
2022-03-31 08:56 derick Note Added: 0006264
2022-04-04 11:32 derick Fixed in Version 3.1dev => 3.1.4